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