> On 27 Nov 2014, at 08:09, stepharo <[email protected]> wrote:
>
>
> Le 26/11/14 21:10, Marcus Denker a écrit :
>>
>>> On 26 Nov 2014, at 19:36, Eliot Miranda <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>> Hi Tudor,
>>>
>>> On Wed, Nov 26, 2014 at 6:02 AM, Tudor Girba <[email protected]
>>> <mailto:[email protected]>> wrote:
>>> Hi,
>>>
>>> As far as I see, the class variables are not slots. Is that correct?
>>>
>>> That's right. They're associations in class pools, and are visible in the
>>> instance-side and class-side methods of the class and all its subclasses.
>>> See Class>>bindingOf: and Class's inst var classPool. Shared pools are
>>> similar. A shared pool stores its variables in its class pool, but other
>>> classes can have its class vars in scope by including the shared pool in
>>> its pool dictionaries.
>>>
>>> If not, how do I get the slots?
>>>
>>> Well, just for clarity (at least I hope it'll bring clarity). One can
>>> access the variables via
>>>
>>> MyClass classPool associations
>>>
>>> Note that these are entirely different from class instance variables, which
>>> are inst var slots in the class object. These hold things like the class's
>>> superclass, its method dictionary, etc. But one can add inst vars to one's
>>> own class. There are many examples of this. Since these slots are
>>> per-class every class gets its own copy of the slot, and because these are
>>> inst vars, they are only in scope in class-side methods of the defining
>>> class and subclasses.
>>>
>>
>> One we did for Pharo4 is to use the Associations of Globals to model these
>> variables as meta-objects (in the same spirit as the Slot objects).
>>
>> Thos means that
>> -> there is an Api to get them
>> -> they have an API to read /write
>>
>> This is just “sugar” on what the associations did already:
>>
>> global := SmalltalkImage classVariableNamed: #CompilerClass.
>> global read.
>> global class
>> ==> ClassVariable
>
>
> but I do not get why a class variable is accessed as a global.
It is not. You have to ask the class for the class variable:
SmalltalkImage classVariableNamed: #CompilerClass.
This returns the class variable ‘CompilerClass’ of class SmalltalkImage.
> To me it looks plain wrong.
> A class variable is like a shared variable between classes. In Clos it was
> the same as an instance variable but with a class scope.
> So could not we make that nicer.
> I really find terrible and an attack against modularity to have them managed
> that way.
Which way?
ah, I think my example was a bad one: I used SmalltalkIamge as it is the class
that comes to my mind that uses logs
of class variables. I do not ask the global namespace anything,
e.g. make a case TT with class var T and it is
TT classVariableNamed: #T
The variable is *not* global. It’s a class variable.
Marcus
