On Wed, Oct 22, 2014 at 2:20 AM, Esteban A. Maringolo <[email protected]> wrote:
> I've been hit by a few side effects of using proxies (GLORP ones), > because some tools like the Debugger and/or inspectors expect some > objects to respond to methods not defined in ProtoObject. > > I discovered this by accident because looking at the stack in the > xterm console I saw a recursion triggered by a halt in > UnitOfWork>>#register: > Such halt caused errors that needed to be printed, and because it was > trigger in the context of a Proxy, boom, infinite recursion. > > Why such methods are not implemented in ProtoObject, or at least with > a "basic" version of it. > Is this by design? Methods like #shouldBePrintedAsLiteral or > #isSelfEvaluating (don't know what it means), along others like > #printStringLimitedTo... etc. > > I remember Steph said a better support for Proxies was in the was > roadmap, how far is that? What can be done to speed this up? > Debugging a proxy object (even one that doesn't use #become:) is really > tricky. > > If you look at the implementation of Glorp's Proxy>>#class it seems it > should answer the class of the proxied object (if materialized), but > all that is commented out returning the receiver class, it is > returning Proxy. If you uncomment that weird things happen. I'll come > back to this later, once I have time to reproduce it. > > At some point, #class was optimized by compiler/vm...simply the source code sending #class would end up with a special bytecode that then the VM would execute. Therefore...the method is never executed...you can even delete ProtoObject implementation of #class and it will work hehehe. Anyway...at some point in Pharo, that was changed and #class was not a special bytecode anymore. THERE you could start interpceting #class. For my proxies....(I was using them before Pharo changed) I simply override the compiler to not optimize #class. Then my proxies would answer the class of the target. Cheers, > Please don't forget not everything inherits from Object :) > > Esteban A. Maringolo > > -- Mariano http://marianopeck.wordpress.com
