Placing new names under standard namespaces?

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.

Regards,
Ammar

On Mon, Oct 25, 2010 at 11:41 AM, Ammar A. [email protected]
wrote:

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.

Kind regards

robert

On Mon, Oct 25, 2010 at 2:55 PM, Robert K.
[email protected] wrote:

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.

| Privacy Policy | Terms of Service | Remote Ruby Jobs