Hello

I was implement proxy for Mocketry project. My proxy (MockObject) can emulate messages sush #printOn: and others that used by tools (debbugger, workspace and others). MockObject just search some tools context in #doesNotUndarstand method context. And if message was sent by tools (not domain code) proxy evaluate it in appropriate way. For example, when #printOn: was sent by debbuger, proxy prints special name instead of record/replay this message.
But search full context chain for each message is really cost operation. But for mock-framework it's not problem I thing.

Maybe tools must mark process in which it work. And proxy would easilly know that message sent by tools.


2010/2/16 St�phane Ducasse <stephane.ducasse@inria.fr>
there is a really nice discussion on supporting (not having an inspector breaking) when browsing
proxy. Can you have a look?

http://code.google.com/p/pharo/issues/detail?id=1970


� � � �"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
� � � �tools."

� � � �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.
_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project