Johan Fabry johan.fabry@vub.ac.be wrote:
ObjectOut defines the message #xxxClass, with implementation "<primitive: 111>", which is identical to #class as defined in Object. So when ObjectOut needs to get its behaviour, it can use #xxxClass.
I had "bad luck" with the details here.
[snip]
As for debugging transparant proxies, two cases can be made: Do you want to debug the proxy or the thing the proxy points to? It is clear that both cases are valid ... So how's the debugger going to know?
In my case I think it got the class from one and used instVarAt: in the other. It looked extremely confusing. I didn't investigate it then, knowing more about these things now perhaps I'll get back to it.
I'd go for a standard behaviour of debugging the thing the proxy points to. After all, we're talking about *transparant* proxies, right? To debug the proxies you'll have to return to basic stuff, such as "Transcript show: foo asString". Ugly, I know ...
I've been thinking about letting the debugger check if #doesNotUnderstand: is redefined and in that case have some extra options. But more importantly whenever something that is not inheriting from Object is debugged the debugger most be very sly. Perhaps the following is good:
ProtoObject "minimal amount of messages" Debuggable(Proto)Object "messages used by debugger (instVarAt: ..) but nothing else" Object
[snip]
That's the nice thing about meta-level programming: you can shoot yourself in the foot in *interesting* ways :-)
Have tried a few.
/Mats
-- "You are more than the sum Johan Fabry - Johan.Fabry@vub.ac.be of what you consume. Vrije Universiteit Brussel Desire is not an occupation." Programming Technology Lab, Room 10F709 -- KMFDM Pleinlaan 2, 1050 Brussels, Belgium
Mats Nygren wrote:
ObjectOut defines the message #xxxClass, with implementation "<primitive: 111>", which is identical to #class as defined in Object. So when ObjectOut needs to get its behaviour, it can use #xxxClass.
I had "bad luck" with the details here.
Poo-poo happens ;-)
As for debugging transparant proxies, two cases can be made: Do you want to debug the proxy or the thing the proxy points to? It is clear that both cases are valid ... So how's the debugger going to know?
In my case I think it got the class from one and used instVarAt: in the other. It looked extremely confusing. I didn't investigate it then, knowing more about these things now perhaps I'll get back to it.
Yes, that must be extremely confusing. There are some weird things going on when trying to inspect a proxy too: There is a big discrepancy between the list of variables given in the listview, and the 'all inst vars' entry in the list. I also do believe that some of this weirdness can be ascribed to the shortcutting of the #class message. (If I remember correctly, thats how I found this bug)
I'd go for a standard behaviour of debugging the thing the proxy points to. After all, we're talking about *transparant* proxies, right? To debug the proxies you'll have to return to basic stuff, such as "Transcript show: foo asString". Ugly, I know ...
I've been thinking about letting the debugger check if #doesNotUnderstand: is redefined and in that case have some extra options. But more importantly whenever something that is not inheriting from Object is debugged the debugger most be very sly. Perhaps the
I do agree, it would be handy if the debugger would be more resourceful for ProtoObject subclasses and/or objects with a redefined #doesNotUnderstand:. But right now, the debugger is a big black box for me, so I'm afraid I can not go much further than the above statement :-(
following
is good:
ProtoObject "minimal amount of messages" Debuggable(Proto)Object "messages used by debugger (instVarAt: ..) but nothing else" Object
I dont think I get the point here... What would be the behaviour of the debugger for ProtoObject subclasses? Forward everything? So when you need to debug the proxy, you would need to change its class?
-- "You are more than the sum Johan Fabry - Johan.Fabry@vub.ac.be of what you consume. Vrije Universiteit Brussel Desire is not an occupation." Programming Technology Lab, Room 10F709 -- KMFDM Pleinlaan 2, 1050 Brussels, Belgium
squeak-dev@lists.squeakfoundation.org