Remove the global Pathname() method
About a year ago I sumbitted an not yet accepted patch for Ruby on GitHub which deprecates the global Pathname() method and adds the . operator to the Pathname class. The patch got ignored, supposedly because I didn't post it here.
I think poisoning the global namespace with methods named after classes should be considered bad style. Instead, all related methods should lie below the Class' namespace. I hope you share that opinion.
As some User once suggested that probably only collection type classes (e.g. Set) should have a . operator, I'm no longer proposing to add . instead to Pathname.
If you like the idea, please let me know. I will modify the patch then.
#1 [ruby-core:49393] Updated by Anonymous almost 4 years ago
First off: +1 on your request about the Pathname(). Although I don't see
the the real problem with it being named after a class. However, I don't
think it's necessary to have a shortcut which is four characters shorter
than the thing it shortens (afaict it is a shorthand of Pathname.new -
does it really hurt to write those four characters?). Also, another
problem I see with it is that it doesn't conform with the usual method
Secondly, I regard Pathname as a collection - in the exact same way I
regard Dir as a collection; a collection of path names that is. And I
think others do too. So I don't see why we shouldn't have said method.
It could even alias to ::glob as Dir does; that would give some
consistency (though I wouldn't mind if we'd continue not to have ::).
P.S.: If I replied wrong in any way, please let me know, as I couldn't
find a guide on how to reply to issues (if it's any different than
replying like in a "regular" mailing list). Thanks!
#4 [ruby-core:49962] Updated by Yusuke Endoh almost 4 years ago
- Status changed from Open to Rejected
As drbrain said, this is the convention in Ruby. There is no reason to hate only Pathname.
Because of compatibility, it is impossible to remove all methods that is named after the corresponding class, i.e., Integer, Array, etc.
Yusuke Endoh email@example.com