One more question. Can all this provide a possibility (in the future) to add inst vars to classes of the foreign packages?
Uko On 19 May 2014, at 14:33, Camille Teruel <camille.ter...@gmail.com> wrote: > > 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
