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 :)

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