[squeak-dev] Re: SmalltalkImage current vs. Smalltalk
andreas.raab at gmx.de
Wed Mar 3 18:20:02 UTC 2010
On 3/3/2010 9:53 AM, Nicolas Cellier wrote:
>>> After discussing this with Stephane Ducasse, I quite agree on this scheme:
>>> SmalltalkImage should better be renamed System.
>>> System soleInstance = Smalltalk.
>>> Of course an optional bakward compatibility module would define
>>> SmalltalkImage current
>> The main thing this does is to create a *third* path that we'll have to
>> support for eternity. I fail to see how "System soleInstance" is any better
>> than "SmalltalImage current".
> Why would you write System soleInstance?
> You will just write Smalltalk.
Oh, I see. Sorry, I misread this, I just saw another cleansing jihad
coming that rewrites all references to SmalltalkImage current with
System soleInstance :-) Never mind then.
> I was speaking of renaming SmalltalkImage (not urgent at all) to
> reflect that Smalltalk is the soleInstance of System.
> And we don't have to rename soleInstance either, it was just for
> explaining the concept.
Yes, that's a significant part of my motivation for option #2 as well.
Having Smalltalk *be* a SystemDictionary isn't really all that useful I
think (although it doesn't really hurt either).
Hm ... now that I've been thinking about it I'm starting to lean for #2
myself a little more.
>> Seriously, if we want to move this stuff forward we should be starting by
>> having a moratorium on adding new methods to the old places and rather
>> discuss where *new methods* should live. This way we learn over some period
>> what works and what doesn't and if we're happy with the outcome then we move
>> a few more bits to those places. The approach of "let's just fix this
>> problem once and forever" simply does not work here because the solution
>> space is too big.
> Using a message indirection like Smalltalk vm certainly helps.
> But sure, it does not solve every problem,
> One day or the other, we will want to change the level of abstraction
> for sure...
>> Concretely speaking, what would be alternative places for the cleanup
>> methods that I just added, and why? Where would you expect them and why? If
>> we have a good place we might start moving a few of the other housekeeping
>> methods over there. To me, this is a much more fruitful direction than the
> I would start with minimal changes and gradually introduce indirection messages.
> Then slowly deprecate message, and provide optional compatibility modules.
> But there, I always prefer a deeper analysis on true code :)
>> - Andreas
More information about the Squeak-dev