On 2 March 2010 23:20, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> 2010/3/2 Igor Stasenko <siguctua at gmail.com>:
>> 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'
>>
>
> like this ?
>
yes

> Smalltalk vm version
> Smalltalk vm extraMemory
> Smalltalk vm listLoadedModules
>
i like it much. From this code its clear what it does!

> But then:
> Smalltalk vm allocationCount
> or Smalltalk memory allocationCount ?
> or Smalltalk gc allocationCount ?
>
Depends to what level you need to decompose things:
vm includes interpreter, and gc.

> Smalltalk host windowSystem
> Smalltalk host platformName
> Smalltalk host osVersion
>
> Smalltalk commandLine vmPath.
> Smalltalk commandLine imagePath.
> Smalltalk commandLine documentPath.
> Smalltalk commandLine optionNumber: 2.

Smalltalk commandLine optionAt: 2.

> Smalltalk commandLine options.
> Smalltalk commandLine argumentNumber: 1.
> Smalltalk commandLine arguments.
>
> Smalltalk sourceCode condenseChanges.
> ...
>
>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>>
>
>



-- 
Best regards,
Igor Stasenko AKA sig.