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.
>
> 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

But the answer is:we don't want to scale !
We want a small manageable Kernel, don't we ?

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.
>>
>>
>