Placing new names under standard namespaces?

[Ammar Ali]

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

 

[Robert Klemme]

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

 

[Ammar Ali]

I can see both positions: changing built in / std lib classes is
typically considered dangerous and a don't. =C2=A0OTOH 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. =C2=A0I'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