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
