[squeak-dev] Re: SmalltalkImage current vs. Smalltalk

Igor Stasenko siguctua at gmail.com
Wed Mar 3 21:43:22 UTC 2010

On 3 March 2010 20:20, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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).

It hurts, because there is no documentation (which is mostly our case
today), and its easy to shoot yourself in own foot
like using #removeKey: instead of #removeClass: and things like that.
Exposing a low-level protocol to the universe is just plain wrong!
Not for you as an expert, but think about newcomers.
Instead of telling users 'please don't use this, or you will be
punished', it is much better to build things in a way,
which will make them hard to abuse (or even better - there will be no
need for abuses), but even if its sometimes needed,
things should be organized in a such way, that there will be clear
understanding what might happen, when he will bypass a  safeguards,
because he will learn from a present architecture and so will think
twice if he doing right thing.

Needless to say, that we should discourage from using globals. That's
why 'Smalltalk tools browse: #foo' is much better than
'ToolSet browse: #foo'. Because its ok, when you have single, well
known root global, but when you having dozens of them scattered over
image.. things become worse and worse.

> Hm ... now that I've been thinking about it I'm starting to lean for #2
> myself a little more.
> Cheers,
>  - Andreas
>>> 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
>>> above.
>> 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 :)
>> Nicolas
>>> Cheers,
>>>  - Andreas

Best regards,
Igor Stasenko AKA sig.

More information about the Squeak-dev mailing list