Ruby Module Naming Convention vs Java Namespaces

[Randy Lawrence]

How do we manage namespaces in Ruby to avoid collisions with 3rd parties?

In Java, they use something like "com.companyname.foo" as a naming
convention which then maps to directories.

In Ruby, how do we name modules so our "foo" module doesn't collide with
a 3rd-party module named "foo" from another company?

 

[Rando Christensen]

How do we manage namespaces in Ruby to avoid collisions with 3rd parties?

In Java, they use something like "com.companyname.foo" as a naming
convention which then maps to directories.

In Ruby, how do we name modules so our "foo" module doesn't collide with
a 3rd-party module named "foo" from another company?

The easiest way to do this would be something like:

require "companyname/module"

and just keep all your libraries within companyname.

Rando Christensen
<[email protected]>

 

[gabriele renzi]

How do we manage namespaces in Ruby to avoid collisions with 3rd parties?

In Java, they use something like "com.companyname.foo" as a naming
convention which then maps to directories.

In Ruby, how do we name modules so our "foo" module doesn't collide with
a 3rd-party module named "foo" from another company?

well, it is not really agreed I think, but I think the most common
convention is to use the style:
General::Specific
I.e. Text::Format, RSS:arser or PDF::Writer

but there are many examples of just SpecificName, like say
ClibPDF or REXML, and few of companyname::module

 

[James Britt]

well, it is not really agreed I think, but I think the most common
convention is to use the style:
General::Specific
I.e. Text::Format, RSS:arser or PDF::Writer

but there are many examples of just SpecificName, like say
ClibPDF or REXML, and few of companyname::module

Yes, but it's unlikely anyone else will release a library named REXML.
But of you are releasing, say, an RSS parser, it needs some naming
arrangement to distinguish it from any other RSS parser.

RSS:arser::Foo
RSS:arser::Bar


James

 

[David A. Black]

Hi --

How do we manage namespaces in Ruby to avoid collisions with 3rd parties?

In Java, they use something like "com.companyname.foo" as a naming
convention which then maps to directories.

In Ruby, how do we name modules so our "foo" module doesn't collide with
a 3rd-party module named "foo" from another company?

I would emulate the built-in/standard library style as much as
possible, i.e., no company names and a General::Specific::MoreSpecific
nest.

If company names absolutely must enter into it, it would be better to
put them at the other end; I'd rather "require
'xml/parsers/AcmeXMLCo'" than 'AcmeXMLCo/xml/parser'. The former is
not ideal, but it's less disruptive and less ungainly than the latter.


David

 

[Robert Klemme]

Hi --



I would emulate the built-in/standard library style as much as
possible, i.e., no company names and a General::Specific::MoreSpecific
nest.

If company names absolutely must enter into it, it would be better to
put them at the other end; I'd rather "require
'xml/parsers/AcmeXMLCo'" than 'AcmeXMLCo/xml/parser'. The former is
not ideal, but it's less disruptive and less ungainly than the latter.

But having the company name as prefix makes installation easier, because
otherwise if your package consists of several modules you'll have to
manage several sub folders.

Regards

robert

 

[David A. Black]

Hi --

But having the company name as prefix makes installation easier, because
otherwise if your package consists of several modules you'll have to
manage several sub folders.

Yes, but all for the common good. I don't see the names of Matz's
company, or those of other core developers, in the standard library.


David

 

[Sean O'Dell]

Hi --



Yes, but all for the common good. I don't see the names of Matz's
company, or those of other core developers, in the standard library.

That's because Matz gets to choose the library names; who can "bump" his
library names? I wanted to give my libraries perfectly ordinary names, such
as with my interface library, but when I used the name "interface" people
went ballistic because someone else had already used the name. I would
gladly get rid of the "celsoft.com" part of library names, but since names
are often decided based on who grabs it first, I have little choice. Well, I
could name my libraries with brand-name style names, like 3DInterfacePro or
InterfaceMagic, or YAIL (Yet Another Interface Library) instead of just
Interface, but I don't particularly care for those sorts of names. Better to
use the most appropriate, simplest name, and just partition it under a domain
name.

Sean O'Dell

 

[Gavin Sinclair]

Hi --

Yes, but all for the common good. I don't see the names of Matz's
company, or those of other core developers, in the standard library.

The standard library should be considered a special case, IMO. I'm
not advocating a particular naming format here, just making that
point.

Gavin

 

[Lennon Day-Reynolds]

The standard library (and other modules that follow the
General::Specific style) also fit the model that CPAN uses, which has
proven itself quite scalable up to thousands of packages.

I think it would be better to encourage highly-descriptive package
names; if anything, it seems that it would be better for authors of
packages which fit the same niche to discover the potential overlap
sooner, rather than later, so that redundant work could be minimized.

Lennon

 

[Austin Ziegler]

I wanted to give my libraries perfectly ordinary names, such
as with my interface library, but when I used the name "interface" people
went ballistic because someone else had already used the name. I would
gladly get rid of the "celsoft.com" part of library names, but since names
are often decided based on who grabs it first, I have little choice. Well, I
could name my libraries with brand-name style names, like 3DInterfacePro or
InterfaceMagic, or YAIL (Yet Another Interface Library) instead of just
Interface, but I don't particularly care for those sorts of names. Better to
use the most appropriate, simplest name, and just partition it under a domain
name.

Unsurprisingly, I disagree. Your "Interface" library could have been
called "Interface::Check"; I personally would have contacted Daniel
and seen if he would have been willing to rename his Interface library
to "Interface::JavaStyle" or something like that. The problem you ran
into, Sean, is that you simply released your library as Interface
without checking to see if there was a namespace collision.

I've run into this problem a couple of times, and in one case, it was
something where I haven't touched the library since (RSS); in the
other, I chose a different name and namespace (Diff::LCS instead of
having a *third* library called Algorithm:iff).

-austin

 

[Sean O'Dell]

Unsurprisingly, I disagree. Your "Interface" library could have been
called "Interface::Check"; I personally would have contacted Daniel
and seen if he would have been willing to rename his Interface library
to "Interface::JavaStyle" or something like that. The problem you ran
into, Sean, is that you simply released your library as Interface
without checking to see if there was a namespace collision.

It's not simply an interface checking library, though; cs/Interface provides a
way to describe interface patterns, apply them to classes, objects and
modules and there are built-in interfaces already applied to some Ruby
built-ins. Interface::Check would not be an appropriate name. The only name
that I felt worked was Interface, which was taken, so putting Interface under
a domain unique to me is entirely appropriate.

Sean O'Dell

 

[Randy Lawrence]

The standard library (and other modules that follow the
General::Specific style) also fit the model that CPAN uses, which has
proven itself quite scalable up to thousands of packages.

I think it would be better to encourage highly-descriptive package
names; if anything, it seems that it would be better for authors of
packages which fit the same niche to discover the potential overlap
sooner, rather than later, so that redundant work could be minimized.

Lennon

Good points.

But this opens up the scenario where a poor-quality module keeps a
common-sense name simply because it was first--while a newer, perhaps
much better library that serves the exact same purpose has to grab a
more esoteric name.

The more appropriate the module names, the more potential for conflict
between modules that provide similar functionality from different authors.

 

[Patrick May]

Hello,

But this opens up the scenario where a poor-quality module keeps a
common-sense name simply because it was first--while a newer, perhaps
much better library that serves the exact same purpose has to grab a
more esoteric name.

The more appropriate the module names, the more potential for conflict
between modules that provide similar functionality from different
authors.

There is a point to having name-space collisions. Open source authors
serve the community by working together. Just segmenting out your
module names has the affect of avoiding each other. Colliding makes
you aware of other projects

And unless it's in the standard lib, I don't really thing any library
has any "right" to a name. If the library writers want to work
together, they can agree on a differentiating naming scheme. And if
they don't care, then they can ignore each other. It probably won't
matter.

Cheers,

Patrick

 

[Robert Klemme]

Hi --



Yes, but all for the common good. I don't see the names of Matz's
company, or those of other core developers, in the standard library.

Well, yes. I should have said (as I did in IRC) that company names
probably do make sense only for company specific parts and not for general
purpose (which the std lib is of course).

Anyway, I don't have the need for a change here. I like it the way it is.

Regards

robert