Michael, I used to work in Java too, and I agree that imports and name
spaces are very uncomfortable :(

And what about Tweak Islands?
http://tweak.impara.de/TECHNOLOGY/Whitepapers/Islands/

I have never use them but for the description they looks like having a
"a module level dictionary", is that right?

(the only thing that I don't like from the examples are that all
objects responds to #island
for me this is not so good, because is mixing different meta levels...
well is the same as: self class :( - I have never used Self, but
Object Mirrors looks like a good idea for me)


On 5/26/06, Michael Latta <lattam at mac.com> wrote:
> 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
> addressed.
>
> 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.
>
> Michael
>
> -----Original Message-----
> From: squeak-dev-bounces at lists.squeakfoundation.org
> [mailto:squeak-dev-bounces at lists.squeakfoundation.org] 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
>
> Hi,
>
> > > 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
>  becomes:
>     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).
>
> bets,
> Ale.
>
>
>
>
> ----- Original Message -----
> From: <goran at krampe.se>
> To: "The general-purpose Squeak developers list"
> <squeak-dev at lists.squeakfoundation.org>
> Sent: Friday, May 26, 2006 7:36 AM
> Subject: Re: Name spaces in Spoon
>
>
> > Hi Ralph!
> >
> > "Ralph Johnson" <johnson at cs.uiuc.edu> 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:
> >
> > http://swiki.krampe.se/gohu/32
> >
> > ...and here is code (I have it updated for 3.9, but haven't published it
> > yet:
> >
> > http://map.squeak.org/packagebyname/namespaces
> >
> > 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
> >
>
>
>
>