On 19 mai 2014, at 14:06, Marcus Denker <marcus.den...@inria.fr> wrote:
> > On 18 May 2014, at 21:42, Johan Fabry <jfa...@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 >
