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?
Randy Lawrence wrote:
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
<eyez@illuzionz.org>
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::Parser or PDF::Writer
but there are many examples of just SpecificName, like say
ClibPDF or REXML, and few of companyname::module
il Mon, 12 Jul 2004 07:07:39 GMT, Randy Lawrence <jm@zzzzzzzzzzzz.com> ha scritto::
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?
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
On Mon, 12 Jul 2004, Randy Lawrence wrote:
--
David A. Black
dblack@wobblini.net
gabriele renzi wrote:
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::Parser or PDF::Writerbut 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::Parser::Foo
RSS::Parser::Bar
James
"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0407120755490.11648-100000@wobblini...
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.
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
On Mon, 12 Jul 2004, Randy Lawrence wrote:
Hi --
On Tue, 13 Jul 2004, Robert Klemme wrote:
"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0407120755490.11648-100000@wobblini...
>
> 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.
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
--
David A. Black
dblack@wobblini.net
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
On Monday 12 July 2004 08:28, David A. Black wrote:
Hi --
On Tue, 13 Jul 2004, Robert Klemme wrote:
> "David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
> news:Pine.LNX.4.44.0407120755490.11648-100000@wobblini...
>
> > 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.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
On Tuesday, July 13, 2004, 1:28:40 AM, David wrote:
Hi --
On Tue, 13 Jul 2004, Robert Klemme wrote:
"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0407120755490.11648-100000@wobblini...
>
> 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.
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 A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0407120825130.28500-100000@wobblini...
Hi --
>
> "David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
> news:Pine.LNX.4.44.0407120755490.11648-100000@wobblini...
> >
> > 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.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
On Tue, 13 Jul 2004, Robert Klemme wrote:
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
On Tue, 13 Jul 2004 06:28:31 +0900, Gavin Sinclair <gsinclair@soyabean.com.au> wrote:
On Tuesday, July 13, 2004, 1:28:40 AM, David wrote:
> Hi --
> On Tue, 13 Jul 2004, Robert Klemme wrote:
>>
>> "David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
>> news:Pine.LNX.4.44.0407120755490.11648-100000@wobblini...
>> >
>> > 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.> 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
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::Diff).
-austin
On Tue, 13 Jul 2004 01:49:08 +0900, Sean O'Dell <sean@celsoft.com> wrote:
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.
--
Austin Ziegler * halostatue@gmail.com
* Alternate: austin@halostatue.ca
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
On Monday 12 July 2004 14:56, Austin Ziegler wrote:
On Tue, 13 Jul 2004 01:49:08 +0900, Sean O'Dell <sean@celsoft.com> wrote:
> 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.
Lennon Day-Reynolds wrote:
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
Hi --
"David A. Black" <dblack@wobblini.net> schrieb im Newsbeitrag
news:Pine.LNX.4.44.0407120755490.11648-100000@wobblini...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.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
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.
On Tue, 13 Jul 2004 06:28:31 +0900, Gavin Sinclair > <gsinclair@soyabean.com.au> wrote:
On Tuesday, July 13, 2004, 1:28:40 AM, David wrote:
On Tue, 13 Jul 2004, Robert Klemme wrote:
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
On Monday, July 12, 2004, at 07:18 PM, Randy Lawrence wrote: