On 24 Jun 2014, at 09:58, Esteban A. Maringolo <emaring...@gmail.com> wrote:
> Hi Stef, > > 2014-06-24 3:18 GMT-03:00 stepharo <steph...@free.fr>: >> Esteban >> >> I would like to know how different are the Glorp proxies from the ones of >> Mariano. >> Because we are thinking about to get by default a nice proxy system. >> Proxies in the sense of object representing one that is not in the system >> (and not proxies >> as metaobject or representing an object that is around as in the JS >> literature). Ideally I would like >> to unify both. > > There's nothing much special about GLORP proxies, and maybe Mariano > knows better. > They have a common superclass named "AbstractProxy" (no NS), and they > work more like "remote references" than anything else. > > They are true proxies, it is, they hold a reference to the realobject, > but no #become is involved in the process. > Also proxies can "release" the referenced object and materialize it > back when needed (according to the proxy strategy). > > Proxy>>#class returns Proxy, but Proxy>>#isKindOf: aClass returns > whether the referenced class is aClass (it is, aProxy isKindOf: Proxy > "false"), #= and #hash causes materialization of the referenced > object. > > Other than that I couldn't find anything else, it's a classical proxy, > with some ORM related stuff. yeah, that’s why I said is not a problem of GLORP proxies but about our treatment of proxies in general :) Esteban > > Regards! >
