On 19 mai 2014, at 14:06, Marcus Denker <marcus.denker@inria.fr> wrote:
On 18 May 2014, at 21:42, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
I understand, thanks for the info.
Let me simplify my question: Using slots is there a reasonably straightforward way for me to intercept variable accesses in all methods within a class?
Yes, you can make a special slot subclass and this defines than the semantics of the slot. You have full control of what code to emit.
This so that I can transparently redirect them to a dictionary lookup.
there will be Dictionay based slots coming with Pharo4, no need to roll your own for that.
In addition, I want to add support for Reflectivity meta links on slots. This means that instead of changing the class definition, you will be able to put a MetaLink on the slot definition (before, after, around/instead). This is for the more âreflectiveâ use cases.
Now this is all in an early state.. the idea is to finish all this over the summer :-)
With Camille we did a quick 20 minute prototype of the whole thing: Subclass of Slot.
Yes it was fun :) To experiment, we did a really simple kind of slot we called ClassSlot that is equivalent to our current class variables.
Opal calles #emitStore: and #emitRead: on slots. the abstract slot has a fall-back that just uses reflection:
emitValue: aMethodBuilder aMethodBuilder pushLiteral: self; pushReceiver; send: #read:
while you can implement it yourself and emit the bytecode that you need. e.g. for the ivarSlot subclass it is
emitValue: methodBuilder
methodBuilder pushInstVar: index.
making Ivar Slots be as efficient as instance variables now.
Marcus