Someone recently pointed out that placing new classes and modules
under standard library namespaces, like Time::Tree or
Hash::Transforms, is frowned upon.
I find this approach increases readability and keeps related things
nicely organized. At the same time I understand that there is a
(slight?) risk of name collisions.
I’m curious what others think, and if there are other risks to be
considered.
Someone recently pointed out that placing new classes and modules
under standard library namespaces, like Time::Tree or
Hash::Transforms, is frowned upon.
I find this approach increases readability and keeps related things
nicely organized. At the same time I understand that there is a
(slight?) risk of name collisions.
I’m curious what others think, and if there are other risks to be considered.
I can see both positions: changing built in / std lib classes is
typically considered dangerous and a don’t. OTOH if you create
extensions e.g. for class Time which are universal (i.e. multiple
users of Time can benefit from this) nesting might not be a too bad
idea. I’d be cautious though.
I can see both positions: changing built in / std lib classes is
typically considered dangerous and a don’t. OTOH if you create
extensions e.g. for class Time which are universal (i.e. multiple
users of Time can benefit from this) nesting might not be a too bad
idea. I’d be cautious though.
Thanks. Drawing a distinction between universal extensions and
extensions that are less so is a helpful rule. And thanks for pointing
out the distinction between built in and std lib classes. I should
stop referring to both as std lib.
Cheers,
Ammar
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.