For me it's ok like it is now.
I updated the GTDebuggers to use slots. For example you can use the bytecode one to see what actually gets executed (and even step into the code of the slot). [image: Inline image 1] Now the other problem is that because reading a slot uses #send:read: the debugger will now stop at that instruction so one has to do an explicit step over to read the actual slot. The logic that performs this check is now isolated in #stepToFirstInterestingBytecodeIn: so we could updated it to take slots into account. Cheers, Andrei On Fri, Jan 16, 2015 at 3:41 PM, Marcus Denker <marcus.den...@inria.fr> wrote: > > > On 16 Jan 2015, at 11:28, Andrei Chis <chisvasileand...@gmail.com> > 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 > > >
