From: Robert Maas, see http://tinyurl.com/uh3t
Subject: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <rem-2008mar15-006@yahoo.com>
Java has a hierarchial namespace for packages. Anyone who owns a
domain on the InterNet, and has sufficient financial resources to
guarantee permanent ownership of that domain, may use that domain
name (with words reversed to yield proper high-order-leftmost
sequence) as a package prefix, then invent any packages whatsoever
with that prefix, and any classes within any of those packages, and
be assured no conflict with anybody else anywhere on the net.
But a person like myself who doesn't own a domain and can't afford
to buy/lease one, can't legally get a Java package prefix.
Common Lisp has only a flat namespace for package names, so it's
rather more difficult to establish a registry for package names
that assures that two different people or organizations won't
accidently name their packages the same. And little guys like
myself who don't own a domain name or copyright or trademark or
anything whatsoever that is globally unique are afraid to make up
any package name whatsoever because as surely as water is mostly
composed of oxygen and hydrogen some bigger fish in the pond will
use exactly the same package name, creating a conflict, and demand
precedence, filing a lawsuit if necessary to prevent me from using
that package name.
So, does there in fact exist any globally accepted registry of
Common Lisp package names, which doesn't require payment of a fee,
but isn't swamped by spammers and squatters and other abusers of
such a free registry, where a little fish such as myself might be
allowed to register a different and guaranteed unique package name
for each major module of software I write? Or at least one master
package to cover all the stuff I personally write??
Because of this not-yet-resolved issue, I haven't bothered to make
up any new package names for my code, since it is no value for my
private use of my own code, and it would be a hassle to avoid
conflicts if I published my code for others to use. I just use the
default package for all my utilities and applications. Depending on
the result of the question I'm asking here, I may or may not start
using (CL) packages in the future.
On Mar 15, 8:56 pm, ·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t)
wrote:
> So, does there in fact exist any globally accepted registry of
> Common Lisp package names, which doesn't require payment of a fee [...]?
I'm not aware of one, but I haven't found package name conflicts to be
much of a problem in practice. If one does occur and the source to
the packages in question is not available, there's always `rename-
package'.
-- Scott
On Mar 16, 5:18 am, Scott Burson <········@gmail.com> wrote:
> On Mar 15, 8:56 pm, ·······@yahoo.com (Robert Maas, seehttp://tinyurl.com/uh3t)
> wrote:
>
> > So, does there in fact exist any globally accepted registry of
> > Common Lisp package names, which doesn't require payment of a fee [...]?
>
> I'm not aware of one, but I haven't found package name conflicts to be
> much of a problem in practice. If one does occur and the source to
> the packages in question is not available, there's always `rename-
> package'.
>
> -- Scott
I agree. Apart from that, and the fact that packages do help and
should be used (period), there are (non standardized) ways to deal
with such issues. ACL has hierarchical packages, and at least CMUCL
has an equivalent implementation; I don't remember OTTOMH what other
implementations do, but I'd bet some of them implement one version of
it.
Another trick I rely on (which, again, is not guaranteed to work) is
to abuse the nickname facility. Suppose I want to write a package
that deals with cuisine. One "regular name" could be "ITALIAN-
CUISINE".
The simple way to do this is to write
(defpackage "ITALIAN-CUISINE" (:use ...) (:export "RISOTTO") ...)
which is fine (please let's refrain from entering the keyword,
uninterned symbols etc debate; it is not the point). As KMP and
others have pointed out it would be better to nickname the package
(defpackage "IT.UNIMIB.CS.ITALIAN-CUISINE" (:use ...)
(:nicknames "ITALIAN-CUISINE")
(:export "RISOTTO")
...)
Organization names do tend to be unique. This has a number of nice
consequences. Most notably, you can leverage the almost always
present CL behavior of signalling something when you define a package
with "conflicting nicknames". E.g. Suppose Marc Battyani wanted to
write a replacement for my package. He'd probably write
(defpackage "COM.FRACTALCONCEPT.ITALIAN-CUISINE" (:use ...)
(:nicknames "ITALIAN-CUISINE")
(:export "RISOTTO")
...)
Suppose that also Kenny wanted to write such a package
(defpackage "COM.THEORYALGEBRA.ITALIAN-CUISINE" (:use ...)
(:nicknames "ITALIAN-CUISINE")
(:export "RISOTTO")
...)
Code using ITALIAN-CUISINE:RISOTTO will continue to "work" (*).
Now, suppose that deep down my loader machinery (load files,
MK:DEFSYSTEMS, ASDF-INSTALLs) I try to load Marc's and Kenny's
packages in an environment that already contains mine. This may
happen because of some deep dependencies resolved by ASDF-INSTALL, so
I would not really know that I'd be needing Kenny's package. I would
(most likely depending on the implementation) get two conditions
because of the nickname conflicts, thus I would be able to at least
know that there are strange library/package dependencies in the setup
I am trying to build.
(*) Of course, I should get a continuable error in the case of Marc's
package and an immediate ABORT in the case of Kenny's package: Marc
is French and knows something about cuisine.
All in all this helps. It is not a panacea and not foolproof, but it
helps exactly in the cases that Robert pointed out. Plus it has
little to do with the hierarchical nature of packages. Of course,
having hierarchical packages would help, but it is not a strict
requirement in this case. Java's package system is nice also because
it maps on a directory structure in the filesystem. Let me make a
final comment. One argument people bring up when talking about this
scheme is about "polluting" the package namespace. I disagree. This
is about precision in naming what is what. After all, polluting the
KEYWORD package is a much more common practice which should be handed
to Nicolas Eymerich da Gerona :)
Cheers
--
Marco
From: Ken Tilton
Subject: Re: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <47dcf7db$0$25035$607ed4bc@cv.net>
Marco Antoniotti wrote:
> (*) Of course, I should get a continuable error in the case of Marc's
> package and an immediate ABORT in the case of Kenny's package: Marc
> is French and knows something about cuisine.
Come on, I just had bottle of beer and some Oreos for breakfast, let's
see Marc top that!
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
In article
<····································@8g2000hse.googlegroups.com>,
Marco Antoniotti <·······@gmail.com> wrote:
> On Mar 16, 5:18�am, Scott Burson <········@gmail.com> wrote:
> > On Mar 15, 8:56 pm, ·······@yahoo.com (Robert Maas,
> > seehttp://tinyurl.com/uh3t)
> > wrote:
> >
> > > So, does there in fact exist any globally accepted registry of
> > > Common Lisp package names, which doesn't require payment of a fee [...]?
> >
> > I'm not aware of one, but I haven't found package name conflicts to be
> > much of a problem in practice. �If one does occur and the source to
> > the packages in question is not available, there's always `rename-
> > package'.
> >
> > -- Scott
>
> I agree. Apart from that, and the fact that packages do help and
> should be used (period), there are (non standardized) ways to deal
> with such issues. ACL has hierarchical packages, and at least CMUCL
> has an equivalent implementation; I don't remember OTTOMH what other
> implementations do, but I'd bet some of them implement one version of
> it.
>
> Another trick I rely on (which, again, is not guaranteed to work) is
> to abuse the nickname facility. Suppose I want to write a package
> that deals with cuisine. One "regular name" could be "ITALIAN-
> CUISINE".
>
> The simple way to do this is to write
>
> (defpackage "ITALIAN-CUISINE" (:use ...) (:export "RISOTTO") ...)
>
> which is fine (please let's refrain from entering the keyword,
> uninterned symbols etc debate; it is not the point). As KMP and
> others have pointed out it would be better to nickname the package
>
> (defpackage "IT.UNIMIB.CS.ITALIAN-CUISINE" (:use ...)
> (:nicknames "ITALIAN-CUISINE")
> (:export "RISOTTO")
> ...)
>
> Organization names do tend to be unique. This has a number of nice
> consequences. Most notably, you can leverage the almost always
> present CL behavior of signalling something when you define a package
> with "conflicting nicknames". E.g. Suppose Marc Battyani wanted to
> write a replacement for my package. He'd probably write
>
> (defpackage "COM.FRACTALCONCEPT.ITALIAN-CUISINE" (:use ...)
> (:nicknames "ITALIAN-CUISINE")
> (:export "RISOTTO")
> ...)
>
> Suppose that also Kenny wanted to write such a package
>
> (defpackage "COM.THEORYALGEBRA.ITALIAN-CUISINE" (:use ...)
> (:nicknames "ITALIAN-CUISINE")
> (:export "RISOTTO")
> ...)
>
> Code using ITALIAN-CUISINE:RISOTTO will continue to "work" (*).
>
> Now, suppose that deep down my loader machinery (load files,
> MK:DEFSYSTEMS, ASDF-INSTALLs) I try to load Marc's and Kenny's
> packages in an environment that already contains mine. This may
> happen because of some deep dependencies resolved by ASDF-INSTALL, so
> I would not really know that I'd be needing Kenny's package. I would
> (most likely depending on the implementation) get two conditions
> because of the nickname conflicts, thus I would be able to at least
> know that there are strange library/package dependencies in the setup
> I am trying to build.
>
> (*) Of course, I should get a continuable error in the case of Marc's
> package and an immediate ABORT in the case of Kenny's package: Marc
> is French and knows something about cuisine.
>
> All in all this helps. It is not a panacea and not foolproof, but it
> helps exactly in the cases that Robert pointed out. Plus it has
> little to do with the hierarchical nature of packages. Of course,
> having hierarchical packages would help, but it is not a strict
> requirement in this case. Java's package system is nice also because
> it maps on a directory structure in the filesystem. Let me make a
> final comment. One argument people bring up when talking about this
> scheme is about "polluting" the package namespace. I disagree. This
> is about precision in naming what is what. After all, polluting the
> KEYWORD package is a much more common practice which should be handed
> to Nicolas Eymerich da Gerona :)
Or, if you're feeling adventurous, you could use Lexicons
(http://www.flownet.com/ron/lisp/Lexicons.pdf) instead of packages and
not have to worry about any of this.
rg
From: Pascal Bourguignon
Subject: Re: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <87d4pupynz.fsf@thalassa.informatimago.com>
Marco Antoniotti <·······@gmail.com> writes:
> [...]
> Organization names do tend to be unique. This has a number of nice
> consequences. Most notably, you can leverage the almost always
> present CL behavior of signalling something when you define a package
> with "conflicting nicknames". E.g. Suppose Marc Battyani wanted to
> write a replacement for my package. He'd probably write
>
> (defpackage "COM.FRACTALCONCEPT.ITALIAN-CUISINE" (:use ...)
> (:nicknames "ITALIAN-CUISINE")
> (:export "RISOTTO")
> ...)
>
> Suppose that also Kenny wanted to write such a package
>
> (defpackage "COM.THEORYALGEBRA.ITALIAN-CUISINE" (:use ...)
> (:nicknames "ITALIAN-CUISINE")
> (:export "RISOTTO")
> ...)
This is the solution I'd preconize too. But I'd avoid to put
nicknames in released defpackage, to avoid these collisions.
I would put in my loader.lisp file:
(load "PACKAGES:COM;FRACTALCONCEPT;ITALIAN-CUISINE.LISP")
(add-nickname "COM.FRACTALCONCEPT.ITALIAN-CUISINE" "ITALIAN-CUISINE")
;; See: http://darcs.informatimago.com/darcs/public/lisp/common-lisp/package.lisp
--
__Pascal Bourguignon__ http://www.informatimago.com/
HANDLE WITH EXTREME CARE: This product contains minute electrically
charged particles moving at velocities in excess of five hundred
million miles per hour.
On Mar 16, 2:48 pm, Pascal Bourguignon <····@informatimago.com> wrote:
> Marco Antoniotti <·······@gmail.com> writes:
> > [...]
> > Organization names do tend to be unique. This has a number of nice
> > consequences. Most notably, you can leverage the almost always
> > present CL behavior of signalling something when you define a package
> > with "conflicting nicknames". E.g. Suppose Marc Battyani wanted to
> > write a replacement for my package. He'd probably write
>
> > (defpackage "COM.FRACTALCONCEPT.ITALIAN-CUISINE" (:use ...)
> > (:nicknames "ITALIAN-CUISINE")
> > (:export "RISOTTO")
> > ...)
>
> > Suppose that also Kenny wanted to write such a package
>
> > (defpackage "COM.THEORYALGEBRA.ITALIAN-CUISINE" (:use ...)
> > (:nicknames "ITALIAN-CUISINE")
> > (:export "RISOTTO")
> > ...)
>
> This is the solution I'd preconize too. But I'd avoid to put
> nicknames in released defpackage, to avoid these collisions.
>
> I would put in my loader.lisp file:
>
> (load "PACKAGES:COM;FRACTALCONCEPT;ITALIAN-CUISINE.LISP")
> (add-nickname "COM.FRACTALCONCEPT.ITALIAN-CUISINE" "ITALIAN-CUISINE")
> ;; See:http://darcs.informatimago.com/darcs/public/lisp/common-lisp/package....
>
Sure, but, IMHO, there is a case when you definitively want the
nickname in the DEFPACKAGE form: when you are developing a new
implementation of a published interface. Of course, this opens up a
different can of worms, but if you implementation does something
sensible with package name and nicknames conflicts then you
potentially get early warnings about what is going on in your
application.
Cheers
--
Marco
Robert Maas, see http://tinyurl.com/uh3t wrote:
> accidently name their packages the same. And little guys like
> myself who don't own a domain name or copyright or trademark or
> anything whatsoever that is globally unique are afraid to make up
> any package name whatsoever because
If you really think this is serious problem, register ENUM. Then you
will have domain name within the domain e164.arpa.
K.
--
From: Kent M Pitman
Subject: Re: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <uzlsyq00z.fsf@nhplace.com>
·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> Common Lisp has only a flat namespace for package names, so it's
> rather more difficult to establish a registry for package names [...]
> So, does there in fact exist any globally accepted registry of
> Common Lisp package names, which doesn't require payment of a fee,
For my own code, I just use the backward domain names convention and
assume that will work. e.g., COM.HYPERMETA.xxx
Kent M Pitman <······@nhplace.com> wrote:
+---------------
| ·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
| > So, does there in fact exist any globally accepted registry of
| > Common Lisp package names, which doesn't require payment of a fee,
|
| For my own code, I just use the backward domain names convention and
| assume that will work. e.g., COM.HYPERMETA.xxx
+---------------
Ditto. Well, ORG.RPW3.etc.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Mar 15, 8:56 pm, ·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t)
wrote:
> Java has a hierarchial namespace for packages.
Lisp allows dots in package names. So you can have a package
foo.bar.xyzzy.
You just can't do partial qualification, for instance use everything
from the foo level, and then use names qualified only by bar.xyzzy.
> Anyone who owns a domain on the InterNet
``InterNet''? LOL
> and has sufficient financial resources
You mean, anyone who, like, has a job?
> Because of this not-yet-resolved issue
As if your list of these wasn't long enough, right? Bummer.
From: Frank Buss
Subject: Re: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <1am3tuo3ge6yj$.wg5fn0duhjon$.dlg@40tude.net>
Robert Maas, see http://tinyurl.com/uh3t wrote:
> But a person like myself who doesn't own a domain and can't afford
> to buy/lease one, can't legally get a Java package prefix.
A domain costs about less than $10 per year, which is about 3 cents per day
(try "domain buy" at Google to find some offers). If this is too much, you
can create a free subdomain at some blog, like blogspot.com and use this,
or even better, create a Sourceforge project and you'll get a free domain,
too, like http://lispbuilder.sourceforge.net/ (but which has a top-level
domain, too: http://www.lispbuilder.org ).
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
From: verec
Subject: Re: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <47dda5f2$0$632$5a6aecb4@news.aaisp.net.uk>
On 2008-03-16 03:56:20 +0000, ·······@yahoo.com (Robert Maas, see
http://tinyurl.com/uh3t) said:
> Java has a hierarchial namespace for packages. Anyone who owns a
> domain on the InterNet, and has sufficient financial resources to
> guarantee permanent ownership of that domain, may use that domain
> name (with words reversed to yield proper high-order-leftmost
> sequence) as a package prefix, then invent any packages whatsoever
> with that prefix, and any classes within any of those packages, and
> be assured no conflict with anybody else anywhere on the net.
> But a person like myself who doesn't own a domain and can't afford
> to buy/lease one, can't legally get a Java package prefix.
What's wrong with:
package com.yahoo.rem642b ;
???
On Mar 16, 4:56 am, ·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t)
wrote:
> Common Lisp has only a flat namespace for package names
I second Ron's suggestion to try his Lexicons framework.
But you can also use the code from
http://www.tfeb.org/lisp/hax.html#HIERARCHICAL-PACKAGES
as a lean solution.
Leslie
On Mar 16, 3:56 am, ·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t)
wrote:
>
> Common Lisp has only a flat namespace for package names, so it's
> rather more difficult to establish a registry for package names
> that assures that two different people or organizations won't
> accidently name their packages the same. And little guys like
> myself who don't own a domain name or copyright or trademark or
> anything whatsoever that is globally unique are afraid to make up
> any package name whatsoever because as surely as water is mostly
> composed of oxygen and hydrogen some bigger fish in the pond will
> use exactly the same package name, creating a conflict, and demand
> precedence, filing a lawsuit if necessary to prevent me from using
> that package name.
>
Just use a hierarchical DNS-structured namespace for package names.
I've done that for at least 6 years, and once you start doing it is'
just obviously right. Domains are very, very cheap. I think we pay £10
(so about $20 I think)) a year for registration, and I am sure there
are cheaper places than the people we use.
From: Pascal Bourguignon
Subject: Re: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <873aqpx028.fsf@thalassa.informatimago.com>
·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> [...]
> So, does there in fact exist any globally accepted registry of
> Common Lisp package names, which doesn't require payment of a fee,
There are several. sourceforge.net, common-lisp.net, etc. Just
create a project on these source repository, and you get automatically
a name like net.sourceforge.your-project
Of course, for private code, you don't need a public name, or nothing
prevents you to invent your own. If you're lucky, it'll be the same
name when you go public.
> but isn't swamped by spammers and squatters and other abusers of
> such a free registry, where a little fish such as myself might be
> allowed to register a different and guaranteed unique package name
> for each major module of software I write?
I would do that. Imagine loading all your code at once. Are you sure
there would be no conflicts? No function redefined differently?
> Or at least one master
> package to cover all the stuff I personally write??
To put all your sources in one package you can have:
(defpackage ··········@REM642B.ALL"
(:use "CL"))
(in-package ··········@REM642B.ALL")
(dolist (src '("utilities.lisp" "macros.lisp" "stuff.lisp" ...))
(load src))
in a separate loader file.
Similarly if you want to put them in different packages, but adding
the :export and :use needed for symbols used accross your new internal
boundaries.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"I have challenged the entire quality assurance team to a Bat-Leth
contest. They will not concern us again."
From: Thomas A. Russ
Subject: Re: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <ymik5k1fann.fsf@blackcat.isi.edu>
·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> Java has a hierarchial namespace for packages.
Not really, except perhaps syntactically. The packages java.util and
java.util.regexp are both different packages. They are just as
different as java.util and org.apache.util. There isn't really anything
that allows you to, say, import java.util.**.* and get everything under
java.util imported. [OK, for classes defined inside other classes,
there is a bit of hierarchy that is mandated by the language, but that's
the extent of it. It also isn't relevant to the remainder of the
discussion.]
There is a convention for mapping these packages onto a hierarchicaly
file system, but there have been development environments for Java that
didn't require following that convention. In any case, it is not a
requirement of the language per se, but simply a convention that made
tool development easier.
> Anyone who owns a
> domain on the InterNet, and has sufficient financial resources to
> guarantee permanent ownership of that domain, may use that domain
> name (with words reversed to yield proper high-order-leftmost
> sequence) as a package prefix, then invent any packages whatsoever
> with that prefix, and any classes within any of those packages, and
> be assured no conflict with anybody else anywhere on the net.
> But a person like myself who doesn't own a domain and can't afford
> to buy/lease one, can't legally get a Java package prefix.
Sure you can. Again, this is just a naming convention, and you can (and
early on people did) choose any name for packages that you want. Of
course, you run the risk of collisions then, but there is nothing
illegal as far as the language goes with not following that convention.
Your code will compile and run.
> Common Lisp has only a flat namespace for package names, so it's
> rather more difficult to establish a registry for package names
> that assures that two different people or organizations won't
> accidently name their packages the same.
Well, except for the convention for mapping Java names to the file
system, there isn't anything truly hierarchical about Java package names
either. They just happen to allow the use of the "." character in the
name in addition to the other standard identifier characters.
Nothing would prevent you from adopting a similar naming scheme for
Common Lisp packages. Some programmers have, in fact, started doing
that. Nothing prevent using names like org.alu.util for a Lisp pacakge
name. You could then call
(org.alu.util:format-date (get-universal-time) :iso8601)
[Note, this example uses made-up names.]
I believe that the portable allegroserve code uses some conventions like
this, at least partially.
--
Thomas A. Russ, USC/Information Sciences Institute
From: Tim X
Subject: Re: CL package system not as nice as Java's, but is it reasonable for me to use it at all?
Date:
Message-ID: <87tzj5zu47.fsf@lion.rapttech.com.au>
·······@yahoo.com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> Java has a hierarchial namespace for packages. Anyone who owns a
> domain on the InterNet, and has sufficient financial resources to
> guarantee permanent ownership of that domain, may use that domain
> name (with words reversed to yield proper high-order-leftmost
> sequence) as a package prefix, then invent any packages whatsoever
> with that prefix, and any classes within any of those packages, and
> be assured no conflict with anybody else anywhere on the net.
> But a person like myself who doesn't own a domain and can't afford
> to buy/lease one, can't legally get a Java package prefix.
>
> Common Lisp has only a flat namespace for package names, so it's
> rather more difficult to establish a registry for package names
> that assures that two different people or organizations won't
> accidently name their packages the same. And little guys like
> myself who don't own a domain name or copyright or trademark or
> anything whatsoever that is globally unique are afraid to make up
> any package name whatsoever because as surely as water is mostly
> composed of oxygen and hydrogen some bigger fish in the pond will
> use exactly the same package name, creating a conflict, and demand
> precedence, filing a lawsuit if necessary to prevent me from using
> that package name.
>
> So, does there in fact exist any globally accepted registry of
> Common Lisp package names, which doesn't require payment of a fee,
> but isn't swamped by spammers and squatters and other abusers of
> such a free registry, where a little fish such as myself might be
> allowed to register a different and guaranteed unique package name
> for each major module of software I write? Or at least one master
> package to cover all the stuff I personally write??
>
> Because of this not-yet-resolved issue, I haven't bothered to make
> up any new package names for my code, since it is no value for my
> private use of my own code, and it would be a hassle to avoid
> conflicts if I published my code for others to use. I just use the
> default package for all my utilities and applications. Depending on
> the result of the question I'm asking here, I may or may not start
> using (CL) packages in the future.
I think this is a non-problem and your creating complexity where none
needs to be.
Consider looking at it from an alternative perspective - how often have
you found that you have conflicts between two packages you are using
because they have the same name?
While java has this so called 'facility', my experience has been that
all it really achieves is large, overly long class path specifiers and
package names that are often much longer than they would need to be.
consider all the other languages which have large numbers of
contributors, like CPAN, they seem to survive OK. What would possibly
help would be a real CLAN where ou could check to see if there are
existing packages that have used the name your thinking of.
Of course, far more important than worrying about name conflicts is to
first actually write a package that anyone would find useful.
Tim
--
tcross (at) rapttech dot com dot au