2009/9/7 Henrik Johansen <henrik.s.johan...@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.duca...@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. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
