2010/3/3 Andreas Raab <andreas.raab at gmx.de>:
> On 3/3/2010 5:57 AM, Nicolas Cellier wrote:
>>
>> 2010/3/3 Andreas Raab<andreas.raab at gmx.de>:
>>>
>>> On 3/2/2010 10:14 PM, Michael Haupt wrote:
>>>>
>>>> Hi,
>>>>
>>>> Am 03.03.2010 um 03:41 schrieb Andreas Raab<andreas.raab at gmx.de>:
>>>>>
>>>>> Consequently I'm going to completely ignore any forward-looking
>>>>> proposals and simply state that the current count is 3 votes for the
>>>>> first variant (Phil, David, Bert) and 1 vote for the second variant
>>>>> (Igor).
>>>>
>>>> here's another for "Smalltalk", then.
>>>
>>> That choice doesn't exist :-) You can vote for:
>>>
>>> a) Smalltalk class == SystemDictionary, or
>>>
>>> b) Smalltalk class == SmalltalkImage
>>>
>>> Cheers,
>>>  - Andreas
>>>
>>>
>>
>> I vote for b).
>>
>> 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.

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.

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