On Tue, Nov 18, 2008 at 12:17:28PM +0100, David Teller wrote:
> This raises two questions: 
> 1) how important is it to allow third-party modules to extend the
> namespace?
> 2) how important is it to offer a uniform package structure (where
> levels are always separated by '.' rather than some level by '.' and
> some by '_')?
> 
> For the moment, we have considered point 1 not very important and point
> 2 a little more. There are several reasons to disregard point 1. Among
> these, clarity of origin (as in "is this module endorsed by Batteries or
> not?") and documentation issues (as in "gosh, this module pretends to be
> part of [Data] but I can't find the documentation anywhere in the
> documentation of Batteries, wtf?").
> 
> Do you believe that we should have chosen otherwise?

Easy - look at CPAN[1].  If you want to scale a project you have to
make decisions that allow a distributed network of people to
cooperate, without needing too much central coordination.  CPAN is a
great example of this loose coupling because packages make their own
decision about naming (albeit they can become "official" later - but
they won't need to rename unless there is an actual naming conflict).

If the problem is documentation or provenance of packages, then add a
mechanism to solve that problem.  Perl also solves this through an
existing, lightweight, distributed mechanism (a standard location to
install man-pages, and a standard man-page format and man-page
generating mechanism -- POD).

Rich.

[1] http://www.cpan.org/

-- 
Richard Jones
Red Hat