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