On 16 Jan 2015, at 11:28, Andrei Chis <chisvasileandrei@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