Very interesting. With a 10-year brain-lock on my own proxy implementation, I need a little help to fully appreciate the nuances of Igor's neat hack.
Ok, so wrap: anObject, clones the Proxy class itself so we can safely blow away its methodDictionary. Is this what causes the VM to fire cannotInterpret:? So then #handleMessage:forProxy: class-side message has access to the proxy's 'object' and the message to send to it.
The part I'm confused about is wrap:. For an ODBMS, I have a 15GB object model, where the in-memory portion of the graph are terminated by Proxy's. When Magma instantiates these endpoints it only knows the integer 'oid', not the object. Apparently, however, wrap: is the method with the instance-creating magic-dust, it wants to know the object to forward to right now, but it's not available which is why a proxy is needed in the first place..
Another question is why is MessageCatchingProxy a variable class? Is it intended that named inst-vars should not be used?
Igor is there a newer version of this?
- Chris
PS - This is really cool, thanks! It's great to discover new cool shit after so many years Squeaking, I'll never be able to outgrow it.
PPS - Even after answers to the questions, I just realized -- My Proxy subclass, even though it appears to inherit from Object, I must remember, when developing, that it does not. And so would I need to reimplement, for example, isNil, ifNil:, ifNil:ifNotNil:,become:, identityHash, etc. all those methods we have now on ProtoObject which I _do_ want to be available to my Proxy..?
On Sun, May 26, 2013 at 7:50 PM, Levente Uzonyi leves@elte.hu wrote:
On Sun, 26 May 2013, Chris Muller wrote:
Why?
Because there's a better way: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-November/132554....
IIRC Igor extended his implementation, and it's probably part of Pharo since 1.x.
Levente
On Sun, May 26, 2013 at 1:11 PM, Levente Uzonyi leves@elte.hu wrote:
On Sun, 26 May 2013, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-cmm.760.mcz
==================== Summary ====================
Name: Kernel-cmm.760 Author: cmm Time: 26 May 2013, 11:25:19.426 am UUID: 523782ae-3096-40ec-8031-77432a691908 Ancestors: Kernel-fbs.759
- Move #isKindOf: to ProtoObject to allow the PointerFinder to work with
Proxies.
Proxies shouldn't be implemented by subclassing ProtoObject.
Levente
=============== Diff against Kernel-fbs.759 ===============
Item was removed:
- ----- Method: Object>>isKindOf: (in category 'class membership') -----
- isKindOf: aClass
"Answer whether the class, aClass, is a superclass or class of
the receiver."
self class == aClass
ifTrue: [^true]
ifFalse: [^self class inheritsFrom: aClass]!
Item was added:
- ----- Method: ProtoObject>>isKindOf: (in category 'testing') -----
- isKindOf: aClass
"Answer whether the class, aClass, is a superclass or class of
the receiver."
^ self class == aClass or: [ self class inheritsFrom: aClass ]!
On 27 May 2013 04:09, Chris Muller asqueaker@gmail.com wrote:
Very interesting. With a 10-year brain-lock on my own proxy implementation, I need a little help to fully appreciate the nuances of Igor's neat hack.
Ok, so wrap: anObject, clones the Proxy class itself so we can safely blow away its methodDictionary. Is this what causes the VM to fire cannotInterpret:? So then #handleMessage:forProxy: class-side message has access to the proxy's 'object' and the message to send to it.
The part I'm confused about is wrap:. For an ODBMS, I have a 15GB object model, where the in-memory portion of the graph are terminated by Proxy's. When Magma instantiates these endpoints it only knows the integer 'oid', not the object. Apparently, however, wrap: is the method with the instance-creating magic-dust, it wants to know the object to forward to right now, but it's not available which is why a proxy is needed in the first place..
Another question is why is MessageCatchingProxy a variable class? Is it intended that named inst-vars should not be used?
i don't remember, why it is variable.. it don't have to be , in fact. :) you are not allowed to access the proxy's state anyways, because it requires sending a message (and sending any message will be trapped by #cannotInterpret:, including sending #cannotInterpret: ).
That's why in my original model a wrapped object involves 2 objects: - an anonymous class with methoddict=nil (handler) - a message trap object (a stateless instance of that class).
when message sent to the trap, it handling it with #cannotInterpret: and passes control to the anonymous class.. Then the rest is up to the class #handleMessage:... implementation, where you can access state etc.. This means that any extra state you need to store (like oid), you store it in anonymous class object.
Igor is there a newer version of this?
Mariano did an extensive work on this (a paper).. i don't know the full details but he implemented a proxy framework, called Marea (or Ghost? i am a bit confused)..
I remember he actually extended the model to be able to store extra state in message-trap proxy (reducing the need of having pair of 2 unique objects per proxy). Please, ask Mariano for details.
(you can find the code at http://www.squeaksource.com/Marea
there is a package, GhostProxies, i think)
- Chris
PS - This is really cool, thanks! It's great to discover new cool shit after so many years Squeaking, I'll never be able to outgrow it.
PPS - Even after answers to the questions, I just realized -- My Proxy subclass, even though it appears to inherit from Object, I must remember, when developing, that it does not. And so would I need to reimplement, for example, isNil, ifNil:, ifNil:ifNotNil:,become:, identityHash, etc. all those methods we have now on ProtoObject which I _do_ want to be available to my Proxy..?
On Sun, May 26, 2013 at 7:50 PM, Levente Uzonyi leves@elte.hu wrote:
On Sun, 26 May 2013, Chris Muller wrote:
Why?
Because there's a better way: http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-November/132554....
IIRC Igor extended his implementation, and it's probably part of Pharo since 1.x.
Levente
On Sun, May 26, 2013 at 1:11 PM, Levente Uzonyi leves@elte.hu wrote:
On Sun, 26 May 2013, commits@source.squeak.org wrote:
Chris Muller uploaded a new version of Kernel to project The Trunk: http://source.squeak.org/trunk/Kernel-cmm.760.mcz
==================== Summary ====================
Name: Kernel-cmm.760 Author: cmm Time: 26 May 2013, 11:25:19.426 am UUID: 523782ae-3096-40ec-8031-77432a691908 Ancestors: Kernel-fbs.759
- Move #isKindOf: to ProtoObject to allow the PointerFinder to work with
Proxies.
Proxies shouldn't be implemented by subclassing ProtoObject.
Levente
=============== Diff against Kernel-fbs.759 ===============
Item was removed:
- ----- Method: Object>>isKindOf: (in category 'class membership') -----
- isKindOf: aClass
"Answer whether the class, aClass, is a superclass or class of
the receiver."
self class == aClass
ifTrue: [^true]
ifFalse: [^self class inheritsFrom: aClass]!
Item was added:
- ----- Method: ProtoObject>>isKindOf: (in category 'testing') -----
- isKindOf: aClass
"Answer whether the class, aClass, is a superclass or class of
the receiver."
^ self class == aClass or: [ self class inheritsFrom: aClass ]!
squeak-dev@lists.squeakfoundation.org