Squeak and Namespaces

Hernan Tylim htylim at gmail.com
Wed Nov 29 15:18:22 UTC 2006


I like Goran solution. Its true that only  fixes the "prefix" problem  and
not the "namespace" problem, as Andreas pointed out. But to me that is not a
bad thing. its one step further to make Squeak a little more comfortable.


On 29 Nov 2006 15:59:41 +0100, Lex Spoon <lex at cc.gatech.edu> wrote:
> 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20061129/2fb7b330/attachment.htm

More information about the Squeak-dev mailing list