On 3/3/2010 3:30 PM, Nicolas Cellier wrote:
> For now, plan A has more votes than plan B.
> plan A: move all SmalltalkImage methods back into SystemDictionary in trunk.
>              Let SmalltalkImage current ^Smalltalk for crossfork compatibility
> plan B: Smalltalk class = SmalltalkImage, Smalltalk globals class =
> SystemDictionary.

Just to be clear: My option #2 only goes until here. I'd like to make 
some actual progress in the near term and your proposal is quite a bit 
of mid- or long-term stuff.

> Advantages of plan B I see for the future:
> - cleaner separation of concerns
> - less vulnerable to refactoring (thanks to messages indirection)
> - compatibility with other forks (Pharo + Cuis + Squeak3.8 + ...)
> easier thru messages

Unfortunately that's all pretty much conjecture or even plain wrong. 
Cleaner separation of concerns is a claim. It's actually *just* the 
claim that was made about SmalltalkImage current and see where that has 
gotten us. So let's try to be careful claiming victory before things 
have even started. Less vulnerability to refactoring won't be happening 
this way either - it's no less vulnerable to get a DNU than it is to get 
an Undeclared. The same goes for the compatibility claim.

The *real* gain regarding refactoring and compatibility will be by 
restoring Smalltalk as the facade that receives those various messages 
and then passes them on to whatever the actual implementation site is. 
Basically we need to be promising that we'll support Smalltalk as a 
facade for all the stuff that SystemDictionary/SmalltalkImage support 
today, but that we won't promise where it'll be implemented in the 
backend. This way we have room to experiment with various locations and 
anyone who needs the compatibility knows there is a safe, idiomatic way 
of doing all this stuff via Smalltalk. The people who want to experiment 
can do that and we can see what we like and dislike.

In other words, there needs to be a very clearly cut line: If you need 
compatibility, you use e.g., Smalltalk allClasses, Smalltalk 
vmParameters, Smalltalk garbageCollect. If you don't, you're free to use 
Namespace default allClasses or VirtualMachine current parameters or 
System soleInstance garbageCollect or Smalltalk vm parameters or 
Smalltalk namespace allClasses. All of these can be delegated trivially 
to from the Smalltalk facade making it very easy to provide the 
necessary level of compatibility while leaving room for innovation.

Cheers,
   - Andreas