Name spaces in Spoon

Michael Latta lattam at
Fri May 26 16:16:40 UTC 2006

Since class names are just used to resolve to an object (unlike in most
other languages where there is special semantics) this proposal is the most
elegant I have seen.  Once again Smalltalk allows extension without new
syntax or semantics because of its deep OO roots.  The only implied
semantics that may be of interest:

1) When a new class is created and inserted into Smalltalk should there be a
new selector that instead inserts it into the SystemDictionary provided as
an argument?

2) I can not think of another implied use of class names that needs to be

My real question about all this is "What is the real issue here?"  All you
get with any namespace system is shorter names that the user must spend more
time interpreting.  If there are multiple implied namespaces (rather than
explicit as in this case) the user must guess what name the compiler is
using.  When there are explicit namespaces as in either proposal below all
you get is longer names than with the current convention.  Having used Java
namespaces for years I suggest that they are mostly not necessary in
Smalltalk.  When binary classes are provided as in Java you must have a
system to prevent classes from using the same name up front.  In Smalltalk
names are only used for compiler access.  So if you have source they can
always be refactored, and if you do not have source you probably do not need
to reference the names except at the boundary of the module.  When
referencing a class at the boundary of a module, a module level dictionary
of classes would suffice.  I think the namespace issue is a non-issue, and
the real issue as Spoon/Montecello has addressed is one of modularization.


-----Original Message-----
From: squeak-dev-bounces at
[mailto:squeak-dev-bounces at] On Behalf Of
Alejandro F. Reimondo
Sent: Friday, May 26, 2006 8:28 AM
To: The general-purpose Squeak developers list
Subject: Re: Name spaces in Spoon


> > It was something like Prefix::ClassName and the point was that only
> > one or two places in the image had to change to legalize that kind of
> > name.
> Yes, the patch to get a Squeak image to accept code using such global
> names is very, very small.

What do you think about sending the name
 as message...
    MyGlobalContext ThisClass
 the global context (aNameSpace, anEnvironment
 or SystemDictionary)
 can respond to the message returning the real
 object (or via dnu build a method to return it)
Using this "trick" we do not need new syntax
 and the solution is solved as usual (sending messages).


----- Original Message ----- 
From: <goran at>
To: "The general-purpose Squeak developers list"
<squeak-dev at>
Sent: Friday, May 26, 2006 7:36 AM
Subject: Re: Name spaces in Spoon

> Hi Ralph!
> "Ralph Johnson" <johnson at> wrote:
> > SystemDictionary needs  to be nested.  Each module should have its own
> I don't agree. :) If you look at 3.3alpha with modules (by late Henrik
> Gedenryd mainly, which was abandoned) it has an elaborate nested
> architecture based on the same idea which Dan actually started with the
> environment instvar etc.
> IMHO one of the reasons that the 3.3 modules adventure ended with
> abandonment was the complexity of imports/exports in a nested hierarchy.
> I advocate having a "flat" model with simply named buckets of names, as
> in my Namespace solution (see below).
> > "global variable Smalltalk", i.e. its own SystemDictionary that holds
> > the names of all classes.  The compiler looks up a name by looking in
> > a dictionary, but a SystemDictionary will look in its parent if it
> > doesn't have its own copy. This way, two modules can each have a class
> > with the same name and the two classes won't collide.
> Yes, all nice in theory. I am however weary of the effects in practice.
> It is quite a step away from the current very simple and immediate
> system, just like the Modules-3.3 was, and look where that ended.
> I simply think that baby steps are needed here. Revolution is fine, but
> risky. An example of "evolution" proving itself is Monticello. By using
> just a few simple tricks it manages to work perfectly inside the
> existing Squeak environment. And that is IMHO the reason for its
> success.
> > I recently read  (probably in squeak-dev) a proposal to standardize
> > the way people use prefixes to ensure that class names don't collide.
> That was my proposal which I have presented on numerous occasions. The
> latest little writeup of it (with tongue in cheek) is here:
> ...and here is code (I have it updated for 3.9, but haven't published it
> yet:
> The very short description is that it adds the ability to have class
> names with the prefix separated using "::". The system will then
> consider the prefix a Namespace and it will even create instances of the
> Namespace class etc. But in the end all classes still hang in Smalltalk
> and all old code works fine. The neat thing is that just like with
> Monticello all old tools work just fine.
> I restricted it to one level though, so there is no hierarchy.
> > It was something like Prefix::ClassName and the point was that only
> > one or two places in the image had to change to legalize that kind of
> > name.
> Yes, the patch to get a Squeak image to accept code using such global
> names is very, very small. This means that old images without this
> support can very easily be patched, IIRC it was 3 methods touched in
> Scanner and Parser or something like that.
> >  If "Prefix" was the module name, and if we ensured that module
> > names were unique, and if importing a module caused all the classes in
> > the module's local version of Smalltalk to be added to the root
> > version of Smalltalk with this prefix added, then very little would
> > have to change in the programming environment.
> As my code actually shows. Just try it. And yes, I should post my 3.9
> version.
> > -Ralph Johnson
> regards, Göran

More information about the Squeak-dev mailing list