From: David Garamond <davegaramond@...>
Date: 2003-01-25T20:16:15+09:00
Subject: Re: Can we attack the 'not enough libraries' thing straight on?

dblack@candle.superlink.net wrote:
> My main qualm about this has always been at the last link in each
> chain -- that is, the "c.rb" in "a/b/c.rb".  One problem is that if
> there's one franchise holder for each potential module space, then if
> that person's module isn't very good, there are all sorts of problems.
> (I'm undiplomatic enough to suggest that this might happen, but would
> probably be too diplomatic and/or cowardly to flag it publicly if it
> did :-)

well, in the CPAN world, a/b indicates category. no single person 
control this so there is room for everybody. you just have to name your 
module sensibly, and if someone else has already taken that name, find 
another sensible one. it's usually not that crowded enough that this 
system works fine until today.

take for instance the Mail:: namespace:

  http://www.cpan.org/modules/by-module/Mail/

as you can see, there are many many mail-related modules, some overlap 
in functionality. for parsing mbox there's Mail::MboxParser, 
Mail::Folder::Mbox, and probably several others that i haven't checked 
out. they seem to live quite happily together and no one seems to occupy 
or take hold of the namespace in a way that makes people think that 
there is only one obvious mbox parsing module.

the good thing about this is that, since there are many choices for a 
particular task, two things might happen:

1) natural selection, survival of the fittest;

2) one or more people will initiate an effort to make a superset/general 
module (e.g. Mail::Box). the resulting module might be good or bad, but 
in the specific case of Mail::Box, the author tries hard to merge all 
the good things from all the other existing modules and tries to do 
things better. it seems, so far so good.

> Another problem is that more than one person might well write
> perfectly useable modules in the same domain, which might differ from
> each other in matters of API but each be to some people's taste.
> There has to be room for these.

yes, there always is.

> That's why, at the very least, I would advocate naming along the lines
> of text/soundex/dbsndx.rb and text/soundex/marcel.rb, rather than
> text/soundex.rb.

yes, fine with me too. at least the "text/soundex" part is there. in 
CPAN there is the modules@perl.org mailing list where people discuss 
these issues. i believe there are some cases where a proposed module 
name/namespace is too general and others recommended another name.

we can also enforce this, if desired. say the first and second level of 
the namespace is reserved for category only.

> (I have no problem with the latter style for things in the standard
> distribution.)
> 
> I admit too that I have a distaste for this kind of categorization,
> because it freezes a particular, sometimes unconvincing snapshot of
> how the pie is sliced.  But I haven't come up with any way to do away
> with it entirely.

well, if there are 1000+ public modules out there (and we like that to 
happen for ruby right?), people will sooner or later tend to organize 
the namespace anyway. it's nice to have one standardized way to do this. 
on the other hand, organizing the namespace _will_ encourage people to 
submit their modules into the community (as is the case with CPAN). so i 
see it as a win-win situation.

-- 
dave