Hi all,


recently, Patrick has raised an interesting question about doIt expression in debuggers/context-relative environments. Here is a concrete example:


Foo subclass Bar subclass Baz

Foo>>something

^ #foo

Bar>>something

^ {super something. #bar}

Baz>>something

^ {super something. #baz}

"Baz new something" answers "#((foo bar) baz)" of course.
Now debug the send and step into Baz(Bar)>>something so that the next send "super something" will answer "#foo".
However, if you select the expression in the contents pane and print-it (you can also do the same in the ContextVariablesInspector on the right), you will get "#(foo bar)" instead.

The reason is that the context-relative doIt will be compiled against the class of the context receiver - which is Baz - instead of the method class of the context. See Compiler >> #classForReceiver:context: and senders.
Here is a very simple patch that could solve this problem:


Compiler>>classForReceiver: receiver context: contextOrNil

-    ^thisContext objectClass: (contextOrNil ifNil: [receiver] ifNotNil: [contextOrNil receiver])

+    contextOrNil ifNil: [^ thisContext objectClass: receiver].

+    ^ contextOrNil method methodClass

So I would like to discuss this behavior: In my opinion, it is definitively confusing that a print-it in a debugger pane behaves differently than actually sending the message. We cannot always reach exactly the same result and behavior, but IMHO we should always strive for it.
On the other hand, especially when working in the ContextVariablesInspector instead of the contents pane, you might indeed expect that your doits are compiled against the actual receiver class. Another consequence of the above patch would be that instance variables defined in subclasses of the context methodClass become unavailable for doits. However, you can still use the left receiver inspector for reaching these variables.

What do you think? :-) Would it be okay to use the lookup class of the selected context's method for context-relative doits or do you have any objections against it? Or do you think it is necessary to distinguish between the ContextVariablesInspector and the contents pane (while I think this would increase the perceived complexity, too ...)?

Looking forward to your opinions - if you do not have any objections, I will send my patch to the inbox soon. :-)

Best,
Christoph

PS1: Note that we would also need to patch Shout styling accordingly. However, this shouldn't be a huge problem.
PS2: When talking about the "execution environment" of doit expressions (not to be confused with the Environment class for bindings!), we might also consider other aspects. Should we maybe also apply process-faithful debugging to them? Until today, stepping vs. doing-it an expression that refers to "Processor activeProcess" in a debugger yields different results ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210312/f007e6ea/attachment.html>