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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Mar 4 00:16:10 UTC 2010


2010/3/4 Igor Stasenko <siguctua at gmail.com>:
> On 4 March 2010 01:50, Nicolas Cellier
> <nicolas.cellier.aka.nice at gmail.com> wrote:
>> 2010/3/4 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>:
>>> 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.
>>>
> It was about removing extra globals from use.
> Smalltalk vm version.  Smalltalk query implementorsOf: #foo
> is better than
> SmalltalkVm version. SystemNavigation implementorsOf: #foo
> because we using less globals :)
>

100% agree of course.
A Smalltalk global is just a static reference to anobject (with early binding).
A Smalltalk message is a late bound invocation of a program.

Which one is enabling conditional execution, security checkings, lazy
initialization, module discovery & loading etc... ?

Nicolas

>>> Nicolas
>>>
>>
>> Just another thought: you might ask does it scale ?
>> No.
>> Having thousands of message or more indirections would just be bad...
>>   Smalltalk vm memory policy doSomething
>>
> will you prefer 'SmalltalkVMMemoryPolicy doSomething'? ;)
>
> The explosion of names have to happen somewhere, when you adding new
> functionality.
>
>> But the answer is:we don't want to scale !
>> We want a small manageable Kernel, don't we ?
>>
>
> indeed.
>
>> 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.
>>>>
>>>>
>>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>
>



More information about the Squeak-dev mailing list