I had some thoughts about the Dir API. I was thinking Dir.mkdir is a little redundant and Dir.mkdir_p is a little strange from an API design. Should dir be in the method if the class is Dir? Seems to me something like Dir.create would be more idiomatic. Also it seems like p should be and option and not a different method. Something like Dir.create("test/dir", parent: true) which is what I think -p stands from from the man pages.
As a total side note I would wonder if this functionality should be rolled into .new?
Yeah, the name is a bit unfortunate. But then it also makes sense as a resemblance of a well-known command-line tool.
Even if there are better alternatives, I’m not sure if it makes sense to rename it at this point. It would perhaps be clearer to use Dir.create. But it’s questionable if the cost for switching are justified by the provided benefit. The current name isn’t really bad in any sense. If starting from scratch, it might not be the best option. But considering existing code bases, it might be the best option to keep it.
I’m not too happy about mkdir_p, though. Again, this resemblance is further moved away because it’s a different method instead of an argument to an existing one. Also I think that parents mode should be the default. That’s what you would usually expect, when you want to create a directory foo/bar/baz/, you want that path to be created, regardless of whether foo/ and foo/bar already exist or not.
So, ideally there should be an optional argument for parents mode and I think it should be enabled by default.
I suppose such an API change would support switching to a different name because then the old methods could be cleanly deprecated instead of silently switching the default behaviour of an existing method.
@kees Interesting to know! Although it still doesn’t need to be exposed as a different function but as an optional parameter, as @straight-shoota mentioned before.