[Pharo-project] About new inspector

Stéphane Ducasse stephane.ducasse at inria.fr
Tue Feb 16 04:45:47 EST 2010


On Feb 16, 2010, at 10:36 AM, Denis Kudriashov wrote:

> 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. 

Cool 
Could you publish your code that we learn?

For debugging speed should not be an issue.
I remember that igor mentioned something related to printOn: / displayString a while ago.
Stef

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





More information about the Pharo-dev mailing list