Pathname can be used as OO interface for filesystem objects, like Pathname("something").mkdir_p or Pathname("something").readlines. Path doesn't seem to have any of that.
expect{ ... }.to_not compile might be a bit much, but is there at least some way to do expect(intVar).to_not respond_to(:+, boolVar)? That's the only case I care about here, but these are fairly important checks as they prevent segfaults.
So Crystal's philosophy, unlike Ruby, is to avoid having too many ways to do the same thing. Crystal has Dir.mkdir_p that takes a String or Path, and that's the only way to do it. Having that in Path would be redundant, with all the downsides that brings (subjective!): discussions between developers around which way is better, or which one should be used here or there; then a larger binary because it's just redundant generated code; it might be slightly inefficient if one calls the other and the optimizer decides not to inline it, etc. That said, in this particular case it might not be that bad, so feel free to open a discussion around that in our forums :-)
And right now there's no way to do responds_to?(:method, args), you can only check if something responds to a method. But this might come later, even in a 1.x version!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Oh,
__DIR__makes perfect sense.Pathnamecan be used as OO interface for filesystem objects, likePathname("something").mkdir_porPathname("something").readlines.Pathdoesn't seem to have any of that.expect{ ... }.to_not compilemight be a bit much, but is there at least some way to doexpect(intVar).to_not respond_to(:+, boolVar)? That's the only case I care about here, but these are fairly important checks as they prevent segfaults.So Crystal's philosophy, unlike Ruby, is to avoid having too many ways to do the same thing. Crystal has
Dir.mkdir_pthat takes aStringorPath, and that's the only way to do it. Having that inPathwould be redundant, with all the downsides that brings (subjective!): discussions between developers around which way is better, or which one should be used here or there; then a larger binary because it's just redundant generated code; it might be slightly inefficient if one calls the other and the optimizer decides not to inline it, etc. That said, in this particular case it might not be that bad, so feel free to open a discussion around that in our forums :-)And right now there's no way to do
responds_to?(:method, args), you can only check if something responds to a method. But this might come later, even in a 1.x version!