[squeak-dev] Re: SmalltalkImage current vs Smalltalk : plan B

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Mar 4 07:02:14 UTC 2010


2010/3/4 Andreas Raab <andreas.raab at gmx.de>:
> 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.
>

Yes I should have told this.
If you stop at B.II you already get compatibility with current forks.
So you can take a pause for a while a think twice.

>> 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.
>

This is a wise position.
I particularly like the "leaving room for innovation".
B.III - B.IV is compatibility with future evolutions.

Nicolas

> Cheers,
>  - Andreas
>
>



More information about the Squeak-dev mailing list