On 19 mai 2014, at 14:11, Marcus Denker <marcus.denker@inria.fr> wrote:

On 19 May 2014, at 07:24, Cl�ment Bera <bera.clement@gmail.com> wrote:

2014-05-18 21:42 GMT+02:00 Johan Fabry <jfabry@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.

Rather, I think that instVarXXX methods (or equivalent) should be exposed in a low-level API as it deals with an object actual representation in memory whereas slotXXX methods should be exposed in a high level API as it's closer to the application domain and to the programmer's intent.

This is an example of the problems we get when we want to add new concepts and features to Pharo.

The problem lies in the interaction between two interweaved languages:

- the high-level language we use to develop

- the low-level language that the runtime (VM) executes.

Currently, both languages are merged (especially in the light of reflection) as their concepts are supposed to map.

But when we introduce something like slots, we mess with this fragile ecosystem since the concepts of both languages doesn't map anymore (field ~= slots).

There is basically two solutions, either we adapt the runtime to close the semantic gap introduced by the new language feature to reunify the LL and HL languages or we explicitly keep both languages.

The first solution requires manpower and the work has to be done each time a new feature is introduced.

If on the contrary we expect our language to evolve, the second solution is better: just another level of indirection.

We have an evolvable language of smalltalkish code, slots and theNewCoolConcept that compiles to an almost fixed language of bytecodes and field offsets.

I think we need this distinction and I'm working on it.

Marcus