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