[Pharo-project] The better debugger support by extending an Object protocol
siguctua at gmail.com
Mon Sep 7 12:28:28 EDT 2009
2009/9/7 Henrik Johansen <henrik.s.johansen at veloxit.no>:
> Well, if the goal is to be able to differentiate between two objects who
> should behave similar in all cases except when you print them while
> debugging, I can't really think of any better ways :)
> Playing the devil's advocate, here's two things to consider:
> - Some people will likely expect *all* proxies to behave like that in a
> debugger, enforcing consistent use may be hard.
> - Some (other) people will likely see debugPrintOn:, and figure it's
> cool to use it for any object they want additional info about at a
> glance in a debugger. (not saying that is necessarily a bad thing)
> Maybe a good way to clarify its intended usage would be implementing
> debugPrintOn: in a ProxyTrait?
> This also ensures a consistent manner for how proxies are distinguished
> from the real. (assuming of course, the implementation for different
> proxies you were thinking of follows a constant pattern)
I'm not focusing this protocol to be used by a proxies only, and as
you mentioned above,
this message could be useful in other cases, when developer would like
to see more detailed info (or formatted differently)
> Personally, I found inspecting the field to see the actual class of the
> object to be of negligible overhead in situations where knowing whether
> it's a proxy or a "real" object is really important.
> So for me, this change falls in the category "not useful enough that I'd
> spend time coding it myself, but useful enough that I'd use it if
> available" :)
Yeah, sum up the extra time you spent (and will spend) for making
and compare this to the time of developing the extra method +
refactoring debugging tools to use new message.
And btw, the actual class of object could be determined by sending a
#class message to it.
But it is happens that in Squeak VM the #class message send
implemented as a hack and it avoids the regular
lookup semantics and reading the class slot of object directly.
In different smalltalks this could not be the case, and btw i strongly
pushing the idea, of getting rid such 'optimizations' like #class, #==
and other. Because this prevents us from having a truly transparent
VM is free to cheat, but it should never get caught cheating :)
> Igor Stasenko skrev:
>> 2009/9/7 Stéphane Ducasse <stephane.ducasse at inria.fr>:
>>> good idea!
>>> We will add that in pharo if you open a bug item ticket.
>> I could add it easily. But first we should make a good expertise, if
>> this change is worth doing.
>> Because for Object it means a trivial addition of a method, but for
>> Debugger/Inspector and other tools
>> this could mean a major refactoring and tracing all calls to printing
>> methods in order to make sure
>> that all of them using new message(s). This could be a big amount of work :)
>>> On Sep 7, 2009, at 5:02 PM, Igor Stasenko wrote:
>>>> Hello guys,
>>>> i'd like to discuss with you an idea of having a specific methods in
>>>> Object class for a better and more clever behavior when debugging.
>>>> For those of you who are using different kinds of proxies, the main
>>>> problem with them that you should override the #printOn:
>>>> or #printString methods in order to behave them similar to what
>>>> original(proxied) object should be,
>>>> but from other side, especially for debugging purposes, this incurs a
>>>> major inconvenience, because you often need to differentiate between
>>>> the real object and object proxy while debugging. Because if proxy
>>>> behaves similar to proxied object while printing, you can't really
>>>> make a difference when looking at it.
>>>> So, i thought that a nice solution would be to extend an Object
>>>> protocol especially for debugging purposes by adding
>>>> and change the debugger to use this message, instead of #printOn: for
>>>> displaying objects in inspector panels.
>>>> Here is the default implementation of
>>>> Object>>debugPrintOn: aStream
>>>> ^ self printOn: aStream
>>>> And, as you may guess, now the proxy could choose to behave
>>>> differently depending on context.
>>>> P.S. Maybe i'm missing a point, and there are already the existing
>>>> good practices how to get around this.. if so, then please tell me.
>>>> Best regards,
>>>> Igor Stasenko AKA sig.
>>>> Pharo-project mailing list
>>>> Pharo-project at lists.gforge.inria.fr
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
Igor Stasenko AKA sig.
More information about the Pharo-dev