Hi andrei once it will be fully working I think that we will need a way to activate it or not. Because for most people Slots will be transparent. But your work is great for slot designers. Keep pushing. Stef Le 16/1/15 16:12, Andrei Chis a écrit :
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).
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.denker@inria.fr <mailto:marcus.denker@inria.fr>> wrote:
> On 16 Jan 2015, at 11:28, Andrei Chis <chisvasileandrei@gmail.com <mailto: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
