On 2 March 2010 22:00, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2010/3/2 Andreas Raab <andreas.raab at gmx.de>:
>> On 3/2/2010 8:55 AM, Igor Stasenko wrote:
>>>
>>> If you remember previous discussion about this, i proposed to use
>>> Smalltalk, which having a 'globals' ivar , which is a SystemDictionary
>>> so, that Smalltalk>>at: x
>>> implemented as
>>>   globals at: x
>>>
>>> then Smalltalk global is an instance of SmalltalkImage , equal to
>>> SmalltalkImage current.
>>> And SystemDictionary is just a dictionary without any extra utility
>>> methods.
>>
>> This is option #2 below. (Sorry I didn't recall your post; otherwise I
>> would've named it the Igor variant :-)
>>
>> Cheers,
>>  - Andreas
>>
>>> On 2 March 2010 18:32, Chris Muller<asqueaker at gmail.com>  wrote:
>>>>
>>>> Smalltalk is a SystemDictionary, which is-a Dictionary.  This suggests
>>>> Smalltalk's main responsibility is mapping the list of global names to
>>>> their global objects, and providing access to them by direct
>>>> reference.
>>>>
>>>> I don't understand why would want to commingle a bunch of utility
>>>> methods in with this primary (global name mapping) responsibility..?
>>>>
>>>> What is the problem exactly?
>>>>
>>>> Also, I'm curious about Cuis compatibility; is this really realistic
>>>> or important?  Why is it important?  This would seem to be a
>>>> relatively superficial difference with Cuis and other Smalltalk's, so
>>>> I hope we will base decisions on what we think is the "right thing" to
>>>> do rather than compatibility with something else that might not
>>>> matter..
>>>>
>>>>
>>>> On Mon, Mar 1, 2010 at 10:08 PM, Andreas Raab<andreas.raab at gmx.de>
>>>>  wrote:
>>>>>
>>>>> Folks -
>>>>>
>>>>> I was just trying to load some other code and once too many I got bitten
>>>>> by
>>>>> this silly SmalltalkImage current vs. Smalltalk stuff, so I'll fix it
>>>>> now.
>>>>> The only question is which way. There are two alternatives which achieve
>>>>> the
>>>>> goal of "SmalltalkImage current == Smalltalk":
>>>>>
>>>>> 1) The Cuis variant: Move all the code back to SystemDictionary;
>>>>> implement
>>>>> SmalltalkImage current as ^Smalltalk.
>>>>>
>>>>> Pro: Compatible with Cuis.
>>>>> Con: Lack of separation of concerns.
>>>>>
>>>>> 2) The inverse Cuis variant: Move all the code from SystemDictionary to
>>>>> SmalltalkImage; add a 'globals' variable (populated by an instance of
>>>>> SystemDictionary) and convert everything roughly like this:
>>>>>
>>>>>        SmalltalkImage current globals: Smalltalk.
>>>>>        Smalltalk := SmalltalkImage current.
>>>>>
>>>>> Pro: Better separation of concerns.
>>>>> Con: Different from Cuis.
>>>>>
>>>>> I really don't care which way we do it; all I want is to get out of the
>>>>> mess
>>>>> we've created by introducing "SmalltalkImage current".
>>>>>
>>>>> If you have an opinion, voice it, otherwise I'll just pick one.
>>>>>
>>>>> Cheers,
>>>>>  - Andreas
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>
> What if instead of writing (SmalltalkImage current) you would just say
> (Smalltalk vm).
> Would this be tolerably short ?
> Would the compatibility layer be short enough ?
>
> Squeak 3.8: SystemDictionary>>vm ^ self
> Squeak 3.9 and upper: SystemDictionary>>vm ^ SmalltalkImage current
>
> I took a look, and except source code management, a majority of
> SmalltalkImage methods are related to VM and command line.
> We could as well move messages to SmalltalkVM and just let a
> SmalltalkImage class current hook
> But I don't think it is necessary.
>
> What do you think ?
>
>
I think we should define a distinctive roles for these parts and make
sure none of them overlap.
'vm' is for tuning/poking GC options/attributes and various
interpreter specific stuff.
'system' is for poking with host system options/attributes
'image' is for poking with language-wide (global) stuff & utils

then , for any behavior it would be clear, what entity is responsible
for it, not like currently
when you don't know what is better 'Smalltalk' or 'SmalltalkImage current'

-- 
Best regards,
Igor Stasenko AKA sig.