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 <[email protected]
<mailto:[email protected]>> wrote:
> On 16 Jan 2015, at 11:28, Andrei Chis
<[email protected] <mailto:[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
