Daniel Vainsencher wrote:

When I go looking for abstractions to reuse, I am less likely to reuse
one that has a namespace prefix because it is "proclaiming" to be
non-generic. So especially for classes that abstract something that may
be widely useful, it is important to not discourage reuse in this way.

Thinking about KCP stuff that is going into the image, I think it should
definitely not use "namespace" prefixes.

======

I heartily disagree with this.  Actually, prefixes exist so that the package is
friendly to other packages that may implement same-named classes and methods.

Hogging generic names without a prefix seems presumptious to me; the idea that
I would dictate to you what a LargeCollection is supposed to be, how it's
supposed to work, and how fast it's supposed to perform.  Once you get outside
the realm of all but the most general-purpose functionality, people don't want
"God" objects that "proclaim" to be the end-all, be-all solution to their
needs.  Sometimes they need the behavior of a LargeCollection, sometimes they
want a MagmaCollection, and sometimes they want both in the same image to do
two different jobs independently.

Prefixes also offer personalization.  When you see a prefix, you should expect
it to fit within the style and patterns of that author, and if it doesn't work
easily with your own patterns, you can choose a different personality that
does. 

To handle the rare case of prefix-collsion, I have a fine suggestion that
allows us to avoid having the long Java-style prefixes.  Create a utility as
part of the package loading that can *rename a prefix* whenever there is a
collision according to the *loading* users desire.

This solution has numerous benefits including simplicity for everyone and
complete customizability for what is important to each person for THEIR image
environment.

Cheers!
  Chris


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com