>
> Could you expand on how ClassVars and Globals are slot-like but not slots.
>
I mean in the sense that there are first class variables where I can make my own
by subclassing.
There is an object describing the var. For Global/Class variable this is the
“binding” from the dictionary where they live.
For class vars, in addition we have a syntax (same as slots) to declare in a
class that you
want to use such a “self made” variable.
In the image there is an example (not a very useful one, more for testing the
mechanism:
LiteralVariable subclass: #ExampleClassVariable
slots: { #state }
classVariables: { }
category: 'Slot-Examples'
with methods:
read
^state
write: anObject
state := anObject
If you make a class with such a class var:
Object subclass: #MyClass
slots: { }
classVariables: { #TT => ExampleClassVariable }
category: ‘Demo'
it compiles e.g. for a read:
tt
^TT
21 <40> pushLit: global
22 <D1> send: read
23 <7C> returnTop
>
> Also, would it be fair to say that for most programming languages
> variables are "dead", and it might be good to distinguish the
> "liveness" of slots. Further, there may be a particular class of
> early adopters who upon hearing the term "slot" that they don't know,
> will be compelled to investigate
>
> btw, can temporary variables be Slots?
Temporaries have objects describing them (created on demand).
You can annotate them (property interface), when you do that, the var is
kept and you get this instance.
There is a reflective API (#readInContext: and #write:InContext:).
It would be possible to continue the implementation to allow subclassing
(and have the compiler delegated code generation to them).
This can be done as soon as we have the need. I wonder if there is a use
case?
What is not that easy is the syntax… of course one could have something like
| #a => MyTemp . #b => MyTemp |
but that is ugly. And a change to the syntax, which I want to avoid.
Maybe a pragma?
<tempClass: MyTemp forTemporaryNamed: #a>
I think this should be use-case driven…
Marcus
