[Pharo-project] The better debugger support by extending an Object protocol

Peter Hugosson-Miller oldmanlink at gmail.com
Mon Sep 7 11:50:40 EDT 2009

On 7 sep 2009, at 17.02, Igor Stasenko <siguctua at gmail.com> 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
> #debugPrintOn:
> method
> 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
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Just one thing: maybe the default implementation could wrap that call  
to #printOn: in an exception handler, in case one is in the process of  
debugging a #printOn: method. The exception could just swallow all  
errors and return a String like 'Receiver cannot be printed' or similar.


More information about the Pharo-dev mailing list