On 19 May 2014, at 07:24, Clément Bera <bera.clem...@gmail.com> wrote:
>
>
>
> 2014-05-18 21:42 GMT+02:00 Johan Fabry <jfa...@dcc.uchile.cl>:
>
> 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. This is easy to do with slots.
>
>
> However we were discussing about that recently with some VM guys, and this
> may be quite slow on our VM. One language that runs on our VM, NewSpeak, have
> similar features (indirection for all instance variable access) and it is
> difficult for them to have good performance. This dictionary lookup case is
> optimized in prototype-based language VMs (Self, Javascript). Usually for
> users it appears that there is an indirection with a dictionary, but the
> implementation does not rely on dictionary for performance.
The nice thing with the Slot idea is that by default, everyone will just use
InstanceVariableSlots which are as fast as now. (the current image, all slots
are ivars, or all ivars are Slots instances).
You will only use Dictionary Slots when you *really* need them (e.g. Morph
could merge most of MorphExtension into Dictioarny and BooleanSlots… it would
even be more memory efficient
and faster than now...
>
> Or am I going to have to override instVarNamed: and hope that works always?
>
> I guess you will also have to override instVarNamed: and/or instVarAt: if you
> want to catch reflexive instVar access.
>
> But that will never always work this method is only for reflective access.
>
instVarAt:, as it reasons about offsets, is very low level…. for slots, it
makes not much sense (as they do not have offsets).
But the idea is to provide a reasonable reflective API…. e.g. slotNamed: (and
maybe instVarNamed: is just an alias of that)
will of course delegate to the slot for reading, taking your semantic change
into account.
Marcus
