> Well, I appreciate all ideas. :)

Don't do it. Absolutely don't. Do not try to "fix" both Smalltalk and the
tools while you are doing what you're doing right now. You just won't have
the time to fix *everything* and if there isn't a migration path (e.g.,
tools like MC continuing to work without being namespace aware yet) you're
loosing. Noone will use what you do (including myself) if the first thing
that happens is that it breaks all the tools. It's not going to work.

Stick with simplest thing that could possibly work. Just have the classes
keep their "full name" and have them available in Smalltalk under that name.
It means tools which use #name will continue to function. Then, for the
future namespace aware tools add messages which can be used to retrieve the
short as well as the fully qualified name.

Unless you consider what you do a merely theoretical exercise (in which case
I won't stand in your way) you should be more concerned with how people
migrate their stuff into a namespace-aware world rather than a few hundred
bytes of wasted space by having classes both in Smalltalk as well as in
their namespace. It might be nicer that way but considering the tradeoffs
... who cares?

Cheers,
  - Andreas

----- Original Message ----- 
From: <goran.krampe at bluefish.se>
To: "The general-purpose Squeak developers list"
<squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, April 15, 2004 1:57 AM
Subject: Re: A little namespace "proposal"


> Hi Bert!
>
> Bert Freudenberg <bert at impara.de> wrote:
> > Am 15.04.2004 um 01:23 schrieb goran.krampe at bluefish.se:
> >
> > > (Smalltalk at: #Fruits::Apple) == ((Smalltalk at: #Fruits) at: #Apple)
> > >
> > > The left hand shows that SystemDictionary has some "compatibility
> > > behaviour" making it seem as if the qualified names are all accessible
> > > "flat" in Smalltalk, which they aren't. It will do a two step lookup
> > > like the right hand shows.
> > >
> > > ((Smalltalk at: #Fruits) at: #Apple) == Fruits::Apple
> > >
> > > Here the right hand shows that Scanner/Parser has been augmented to
> > > properly handle qualified names (with a little help from Andreas).
> >
> > Does that mean I can not enumerate all classes in the system by looking
> > at the entries in Smalltalk?
>
> I have tried to make SystemDictionary keep the appearance up. :) But I
> am still digging through the image to make sure it is tight. For
> example, there are still allClasses, allClassesDo:, classNames (giving
> qualified names) etc.
>
> > What about the invariant
> >
> > (Smalltalk at: aClass name) == aClass
> >
> > If this does not hold, many tools would have to be made
> > namespace-aware.
>
> Yes, I know - but this holds:
>
> (aClass environment at: aClass name) == aClass
>
> > This can be elegantly avoided when using the
> > fully-qualified name as actual class name. I thought your original
> > proposal did this?
>
> Yes. :) But I got annoyed with having classes both in Smalltalk and in
> the Namespace instances - redundance makes me itch. Craig also
> criticized me for "misusing" the name instvar in Class. :)
>
> If this turns out to be too hard - we can always back down to that
> solution. I am not sure yet. It would be so very, very nice to see a
> Smalltalk with just about 30 entries. :) Anyway, it is a "small problem"
> all in all I think. Using qualified names for classes would also force
> us to go through a lot of tools because you don't want to see the
> qualified names in the browsers all the time.
>
> On the other hand I am right now a bit stuck on SystemOrganization
> because it just associates the class name with a single category. So
> this breaks. Earlier today I created Fruits::Orange and Test::Orange in
> two different categories and then of course one of them "disappeared" in
> the Browser. :) And having them both in the same category would make the
> class listing pretty confusing without qualification...
>
> Well, I appreciate all ideas. :)
>
> > - Bert -
>
> regards, Göran
>