> On 16 Jan 2015, at 11:28, Andrei Chis <[email protected]> wrote:
>
> Hi Marcus,
>
> So now ' self class allSlots ' should be used also in the debugger to get the
> instance variables of an object?
>
Yes, at least for now… I am not yet that happy with the naming… it is hard to
get consistent *and* be resably compatible….
So the idea is that the old API for (instVarAt:, instVarNames…) continues to
work *but* this shows (and manipulates)
what is really there. VM level instance variables.
Slots are first class instance variables that
a) might redefine what happens of read/write
—> all reflective read and write needs to go through
the slots.
b) they often correspond 1:1 to a low level ivar, but they don’t have
to (e.g. the TestSlot in the example has no underlying ivar)
—> we need to ask for all Slots, not just all
instVarNames.
For the naming… in some way Slots are just “First Class Instance Variables”
that map to VM level Fields.
Sometimes I feel it would be nice to use just these two for naming: Fields (VM
Level) and Instance Variables (Image level, aka Slots).
But then, there is backward compatibility to be taken into account… we can’t
really change instVarAt:… but we could of course keep
those for legacy and use the “long form” for the “reified” instance variables:
instanceVariableNamed:, #instanceVariableNames, and so on…
To make it really consistent and just use “Field and Ivar", there would be a
lot to be changed: names of byte codes, for example.
So maybe having it like it is now is good? “Field and Ivar” are one concept,
while the high-level one is “Slot”.
I am not sure myself… I have to admit.
Marcus
