>> I just want to something to the story. I'm not satisfied with 
>> SystemDictionary and SmalltalkImage as there are in 3.8 because
>> it is difficult to find what and where. The situation is like that 
>> because we are in the middle of the changes. This is why I would have 
>> prefered that we fixed it once for all. (for example by having 
>> SystemDictionary = only a namespace and SmalltalkImage = all the rest 
>> of SystemDictionary that can't move in another place But this path 
>> was the most unstable for external users (mistake of mine)).
>
> Thanks for clarifying. Your original approach makes a lot of sense 
> (especially in light of what I see in other Smalltalks). I wonder if I 
> should not propose an approach which makes more sense in light of your 
> original vision while keeping the functionality that people have come 
> to rely on.
>
> * SystemDictionary becomes a namespace only. If you like we can rename 
> it Namespace.

But it can be "namespace only" if it does not have to support all the 
default systemDictionary methods
even via delegation.

> * Namespace gains a subclass: RootNamespace. Smalltalk is an instance 
> of RootNamespace.
> * RootNamespace has an inst var, myimage, which holds an instance of 
> SmalltalkImage. RootNamespace has a lot of methods (it looks like the 
> old crappy SystemDictionary class); the stuff that SystemDictionary 
> used to do that has been factored into SmalltalkImage gets delegated 
> as a message sent to myimage.
> * An alternative approach would be to override doesNotUnderstand: in 
> RootNamespace, causing it to pass the message on to the SmalltalkImage 
> class in case of a method which belongs to it instead of 
> RootNamespace. (This is probably pretty hacky, and flirting with the 
> Powers of Darkness.)

In the namespace proposal we published on SqueakSource, we do not want 
to use inheritance to model nested/hierarchical namespace because we do 
not know if we need that and we would prefer to have import over 
parent/inheritance hierarchy.
Inheritance is over used.

> The end result is that the rest of the world can still say "Smalltalk 
> doThis" or "Smalltalk doThat" and despite the refactoring into 
> Namespace and RootNamespace, everything'll still work; Smalltalk just 
> delegates the SmalltalkImage stuff to an actual SmalltalkImage.

with the new proposal we described everything would work: Smalltalk bla 
and SmalltalkImage uniqueInstance blue and we could also do Namespace 
smalltalk.

Smalltalk is an instance of SmalltalkImageSystemDictionary, it 
delegates namespace business to Namespace.
People can add the stuff they want in Smalltalk (we are not the keeper 
of that class), old code loads via deprecation,
namespace has a backward compatible interface.  And slowly the use of 
SISD as namespace gets deprecated and tools
can become slowly namespace aware if needed.

> Do you see where I'm going with this?

I see, I think that we do not know if we need a rootnamespace at all. 
So I prefer our solution :).

>  Does that resemble what you're doing? I'm not sure what everyone's 
> big problem is with the new approach, except not being able to send 
> messages to Smalltalk anymore in the way they've been doing.

I do not know I guess that andreas was mad because we got stuck in the 
middle of the other approach that was breaking
a lot of old clients. Because you had to use SmalltalkImage or 
Smalltalk and know it. And this is what the new proposal tries to fix 
without killing the idea to have back the original intention of 
environment (or namespace) notion in Smalltalk (because
environment was defined looonnngg time ago on Behavior).

I hope that you understand better the solution we propose especially as 
it is less intrusive in people's life.

Stef

PS: I guess that this solution was not clear when we did the current 
approach since Namespace is a kind of dangerous name to use.