Hi Esteban,

You may want to check some proxy implementations I did. You can check Ghost proxies in my PhD thesis:����http://rmod.lille.inria.fr/archives/phd/PhD-2012-Martinez-Peck.pdf�� and here:��https://hal.inria.fr/hal-00877757/PDF/main.pdf

One of the things I did was to be able to enable (could even be done dynamically) ��debugging capabilities to proxies..that is...proxies would understand theirself all necessary methods for inspecting/debugging/printing/exploring them without actually intercepting the message. You can read about that in the above links. As a quick prototype.... you way want to create a subclass of ProtoObject or directly add those messages to the Glorp proxy.

Also...AFAIK, Camille Teruel was doing some stuff with Ghost Proxies, so he might have the latest version available somewhere. In anycase, my original code was in:��http://ss3.gemstone.com/ss/Ghost ��but saw there is also:��http://smalltalkhub.com/#!/~CAR/Ghost/ �� which may be newer.��

Cheers,��

On Wed, Oct 22, 2014 at 2:20 AM, Esteban A. Maringolo <emaringolo@gmail.com> 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.

Please don't forget not everything inherits from Object :)

Esteban A. Maringolo

--
Mariano
http://marianopeck.wordpress.com