[Pharo-project] About new inspector
stephane.ducasse at inria.fr
Tue Feb 16 03:21:23 EST 2010
there is a really nice discussion on supporting (not having an inspector breaking) when browsing
proxy. Can you have a look?
"What happens is the inspector asks for "self class allInstVarNames"
and then tries to get each value with "self instVarNamed: aName". The
problem is, self class allInstVarNames answers the instVars of the
future class, but "self instVarNamed: aName" gets passed up to the
MIMEDocument by #doesNotUnderstand: and the MIMEDocument throws an
error because of course it doesn't have the correct instant vars.
The old inspectors weren't as intrusive and worked, these new tools
clearly still have some bugs. Since ProtoObject, the superclass for
any such proxies doesn't do #instVarNamed:, such code in the inspector
will blow up anytime one attempts to inspect any kind of proxy. I
would report this as a bug to whoever is maintaining the new inspector
So the only way I know to produce the 'bug' is to load the SFuture class he describes
in the blogpost I mention above then run the example I posted in step two. If this
is the wrong place to report this then let me know and I'll keep looking for the
Delete commentComment 4 by pdebruic, Today (14 hours ago)
The default, I think. I haven't changed anything.
SystemBrowser default Ctrl-p gives OBSystemBrowserAdaptor
Delete commentComment 5 by marcus.denker, Today (11 hours ago)
I think the problem is this:
-> ProtoObject implements a *minimal* object. This way, Proxies or Futures can use #doesNotUnderstand
to implement what they implement. That is, for the example of the Proxy, every message is forwarded to the
-> Now we do not know what exactly you want to forward. Should an inspector inspect the local proxy? Ot the
remote object? You decide. Your subclass of ProtoObject copies as many objects from Object as you want.
(often all that are needed to inspect the *proxy* vs. the remote object).
I think Ramon fine-tuned his implementation for the normal old inspector. Now when you use another one,
it uses other methods in addition to the one implemented in the Future --> confusion. Chaos. Bug.
But: We can not fix this. this is purely the responsibility of the implementor of the subclass of ProtoObject.
So. next action:
-> We fix (uhm, remove) the croquet Future code that is just plain confusing.
-> We think hard if it's really a problem in the new inspector vs. a missing method on the Future.
(and, yes, all this sucks anyway.... we are hard at work to make reflection better and solve all this in a *much*
nicer way... but that's research...)
Delete commentComment 6 by ramon.leon, Today (10 hours ago)
It's not just the Future proxy that'll have problems, it's proxies in general. The
way the current inspector is written won't work with any proxy I see in my image,
SoapHref, SFuture, MAProxyObject, MADynamicObject, probably the Glorp record proxy,
because it assume it can use #instVarNamed: on an instance using values from
"anInstance class allInstVarNames" which in the case of *any* proxy won't work unless
the proxy implements a version of #instVarNamed:.
This is confusing because now the proxy is no longer behaving as a proxy, now
reflectively it's answering values for itself rather than the instance being proxied.
Another solution would be if the proxy overrode #class to return the class of the
proxied instance, but I've always assumed all hell would break loose if you overrode
#class, I didn't think it safe to do, and I've not seen any other proxy class do this.
Regardless of the ultimate solution, the inspector shouldn't blow up, it should catch
the exception and have some default rendering behavior for when it can't inspect an
object for some reason. Do you not agree?
Delete commentComment 7 by stephane.ducasse, Today (moments ago)
Yes I agree.
We should contact frederick.
I think that the inspector should know that it is browsing a proxy and pay attention.
More information about the Pharo-dev