[Pharo-project] The better debugger support by extending an Object protocol
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.
good idea! We will add that in pharo if you open a bug item ticket. Stef 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 #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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/9/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
good idea! We will add that in pharo if you open a bug item ticket. Stef
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 #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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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) 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" :) Cheers, Henry Igor Stasenko skrev:
2009/9/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
good idea! We will add that in pharo if you open a bug item ticket. Stef
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 #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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/9/7 Henrik Johansen <henrik.s.johansen@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) while debugging.
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 additional 'lookup' 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 proxies. VM is free to cheat, but it should never get caught cheating :)
Cheers, Henry
Igor Stasenko skrev:
2009/9/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
good idea! We will add that in pharo if you open a bug item ticket. Stef
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 #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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
On 7 sep 2009, at 17.02, Igor Stasenko <siguctua@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@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. -- Cheers, Peter
2009/9/7 Peter Hugosson-Miller <oldmanlink@gmail.com>:
On 7 sep 2009, at 17.02, Igor Stasenko <siguctua@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@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.
AFAIK, debugger already having a work-arounds for this, so if #printOn: throws an exception it displays a reddish string , "object can't be printed, try debug object printString" or similar. What is interesting about that, that at some point, the source of such errors could be that an object which you trying to print is not fully initialized because developer do not expected the usage of #printString at early stages of object initialization, but this often happens in Debugger when you evaluating the code step-by-step. This just another case, where separate #debugPrintOn: could be useful. But i don't want to make it too clever in the Object, as you proposing, instead, i think it should be plain stupid and act as an entry point, while one who overriding this message could make sure that #debugPrintOn: never throws an exception... But still, this doesn't means that debugger should not care about such things by itself.
-- Cheers, Peter
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I think it is a reasonable approach. GemStone has a few debugger switches which affect the debugging of proxies ( at least stubs) so I mention that since it is a similar area. Where your extension perhaps wouldn't scale is if this became an enthusiastic growth of API if you found other useful things to do as well. Another way to look at it would be to implement a per process or dynamic variable that objects could access like self debuggingContext where the object could find out about it's current execution environment. In your proxy objects you would access this in the print method. I'm not sure if it is a good idea or not but such an object could then hold onto more complex state. Eg stub debugging, print policy, debugging replication specs etc. Just a thought cheers mike On Monday, September 7, 2009, Igor Stasenko <siguctua@gmail.com> wrote:
2009/9/7 Peter Hugosson-Miller <oldmanlink@gmail.com>:
On 7 sep 2009, at 17.02, Igor Stasenko <siguctua@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@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.
AFAIK, debugger already having a work-arounds for this, so if #printOn: throws an exception it displays a reddish string , "object can't be printed, try debug object printString" or similar.
What is interesting about that, that at some point, the source of such errors could be that an object which you trying to print is not fully initialized because developer do not expected the usage of #printString at early stages of object initialization, but this often happens in Debugger when you evaluating the code step-by-step. This just another case, where separate #debugPrintOn: could be useful.
But i don't want to make it too clever in the Object, as you proposing, instead, i think it should be plain stupid and act as an entry point, while one who overriding this message could make sure that #debugPrintOn: never throws an exception... But still, this doesn't means that debugger should not care about such things by itself.
-- Cheers, Peter
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Henrik Johansen -
Igor Stasenko -
Michael Roberts -
Peter Hugosson-Miller -
Stéphane Ducasse