Sounds good. Could you read the paper guille sent to esug on the analysis use of sharedpools because having first class instance variables can really help us to make the system more explicit. Right now we have tons of different caches way to expression session reinitialization recreation on load (fuel and other). Stef On 3/7/14 17:51, Marcus Denker wrote:
Hi,
If we have meta-object describing (and thus having the power to change the semantics of) instance variables, we need the same for Globals.
I think the easiest is to just re-use the object hat is already there: the âbindingâ, that is, the association from the dictionary where the global lives (e.g. the classPool for class vars, Smalltalk globals for true globals, and so on).
SystemVersion bindingOf: âCurrent'
The VM just cares that it is an assoiation (actually, it just care that there are two fields, but the rest of the image cares about value and keyâ¦)
-> we can make a subclass of Association -> we can have the compiler forward code generation to the object that describes the global -> we can add a nice MOP API: #read and #write: (instead of #value and #value:) -> Programmers can subclass the GlobalVariable and change #read and #write like they want (or override the code gen methods) as in Slots.
The only drawback is that you can not add an instance variables, I think, to check⦠maybe it even works? If not, there are ways around that e.g. using some fancy Slot that does not need an ivar but uses a weak dictionary in a class variable, for example).
Thus: it would be fairly easy to have the class vars be as flexible as the slots⦠and then e.g. you will be able to put breakpoints and watchers on class vars. You could even define globals with special behaviour the same way as you do with Slots.
Marcus