[Pharo-project] About new inspector

Stéphane Ducasse 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
	correct place.  

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
	remote object.
	-> 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 mailing list