Squeak and Namespaces

Lex Spoon lex at cc.gatech.edu
Wed Nov 29 14:59:41 UTC 2006


Andreas Raab <andreas.raab at gmx.de> writes:
> Generally speaking, I'm -1 on the proposal, mostly because what the
> proposal doesn't achieve is to make a real step towards enabling
> scalability of development (which to me is really what we're
> after). That's because the *author* of some code still needs to find
> unique names (prefixes) that do not conflict with the rest of the
> world and that a "change of prefix" becomes very, very expensive
> because it's literally like renaming all of the classes at once (and
> consequently breaking all of the code that uses any name from that
> "prefix space").

It's a good observation.  Nonetheless, a hierarchical global namespace
seems a good step forward over a flat global namespace.  I do not know
about *this* system, but in general I would love if global variables
and classes had long hierarchical names.  Using the existing class
categories would seem great for that.

Right now, responsible programmers already fake a hierarchical
namespace by putting prefixes in front of all their global names.  At
the very least, it would be nice to support this practice in the
programming language.  Ideally, you can even use long names
("Monticello") instead of short prefixes ("MC") and thus greatly
reduce the chance of conflicts.

In practice, I bet it's not so hard to pick prefixes that are unique
in the contexts the package will be used in.  Most of the time, you
can just use the name of the project, which you have surely already
gone to some efforts to try and make unique.  If nothing else, all the
open-source projects would benefit!


Finally, keep in mind what the great naming systems you describe for
the future would look like.  They will probably still have path-based
identifiers!  The only difference from hierarchical names would likely
be that the path can start from somewhere other than a single global
root.  Thus, a flexible hierarchical-naming system would seem like a
good basis for the kind of naming system you are thinking about.  (In
particular, you would want Foo::Bar to really mean "Bar" within
"Foo"....)



-Lex




More information about the Squeak-dev mailing list