Hmm. I think I just like sending messages to something called
Smalltalk when I want to talk with the system. I'm totally ambivalent
about what it's implementation is; I've really only had to care once
thus far. But I really think calling it Smalltalk as an idiom is
clearer and more intuitive than calling it SmalltalkImage. Whether or
not it's a SystemDictionary doesn't matter that much to me. OTOH, it
confused the *crap* out of me at first when I kept trying to browse
Smalltalk (out of only curiosity) and the browser kept opening
something called a SystemDictionary. I expected that Smalltalk, having
a capital 'S', would be a class.

That's what I meant about aesthetics, which may be the wrong word.

On Wed, Mar 3, 2010 at 4:16 PM, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 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.
>>
>>
>
>



-- 
Ron