class variable slots?

On 26 Nov 2014, at 19:36, Eliot Miranda <[hidden email]> wrote:

Hi Tudor,

On Wed, Nov 26, 2014 at 6:02 AM, Tudor Girba <[hidden email]> 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. 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.
Why the compiler instead of going to Smalltalk the global namespace cannot ask the class that declares it?
Even if we would have modules I do not see why a class var should be a module global because it is not what it is.
I think that the original implementation is not aligned with the semantics.

Then, I added that the Compiler actually delegates code generation for read and write

to these meta-objects, meaning you can subclass them and add special kinds of Globals 

with special semantics (just like Slot Subclasses). This could be used for e.g.active globals

that announce when changed.

But the real use-case for this is putting meta-links on these globals.

e.g. add a class TT with class var T and a method that reads it.

|link |

link :=  MetaLink new 

metaObject:  Halt;

selector: #now.

(TT classVariableNamed: #T) link: link.

TT new readT

-> halt.

This means that we can out break-points on class variables (as opposed to a single read or write).

This all needs a bit more work to be really usable… 

Marcus

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.

ahhhh ok

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.

Ok we are safe :)

Marcus

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

14562 add a Users tab to GTInspector for Slots and LiteralVariables
https://pharo.fogbugz.com/f/cases/14562

Marcus Denker wrote:
Is it feasible to get highlighting of 'Object' as well?
cheers -ben

In System Browser, right-click on a class > Analyse > Class refs...
or, select some text e.g. 'Object' > Extended search...>references to it

and in both cases there is highlighting of the search for class, which I
find useful.
cheers -ben

Tudor Girba wrote: