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. 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
