On 27 Nov 2014, at 08:09, stepharo <stepharo@free.fr> wrote:

Le 26/11/14 21:10, Marcus Denker a ��crit :

On 26 Nov 2014, at 19:36, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Tudor,

On Wed, Nov 26, 2014 at 6:02 AM, Tudor Girba <tudor@tudorgirba.com> 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?