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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Wed Mar 3 23:44:24 UTC 2010


2010/3/4 Igor Stasenko <siguctua at gmail.com>:
> On 4 March 2010 00:45, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 2010/3/3 Igor Stasenko <siguctua at gmail.com>:
>>> 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.
>>>
>>
>> We could ask why memorizing a message name is simpler than memorizing
>> a global name ?
>> Well it's not.
>>
>> Unless we use poor semantics in class names (Framework Handler System
>> Management.etc. are not so informative.keywords...).
>> We feel forced to use such silly names because we are in a global namespace...
>> For messages, the namespace is a bit more local.
>>
>> So why using a message would be better than a global ?
>> -1) because of the tools: we get a well known entry point for
>> browsing: Smalltalk
>> -2) because the message can redirect to any object, eventually conditionnally
>> -3) it is much easier to refactor code while maintaining
>> compatibility: just change an implementor instead of many senders
>> and we need to refactor when introducing new abstractions...
>>
> this is also means better modulatiry.
>
> -4) Because of the way of thinking. First thought, when you need
> something to do is: 'I need to find method',
> not 'I need a SystemNavigation to find a method'. This means, that
> initially, to describe our intent we using verbs, which characterizing
> what you going to do,  and only then we going to next question 'what
> is a proper tool to do that?'  or 'what object(s) should be used to do
> that?'. And in this way we are forming a message - selector is verb,
> and receiver is noun.

Well, not exactly here, we are complexifying the grammar a bit:

Smalltalk vm
Smalltalk commandLine

This are just nouns at genitive case... The verb will follow.

Nicolas

> And, obviously, because of that, first thing which one going do is to
> look for implementors of 'find' or 'findMethod', because it is really
> irrelevant who is implementor, once it satisfies the need. And so, it
> is not important to have a global with nice name which will reflect
> what it is used for or its potential behavior
> (AlternatePluggableListMorphOfMany - sorry Chris, can't resist :), but
> much more important to have a properly named methods which
> implementing this behaivor.
>
>> Maybe some will see other advantages (security ?)
>>
>> Nicolas
>>
>>>> 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.
>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>



More information about the Squeak-dev mailing list