cannotInterpret: MessageCatchingProxy (was: The Trunk: Kernel-cmm.760.mcz)
Locked
cannotInterpret: MessageCatchingProxy (was: The Trunk: Kernel-cmm.760.mcz)
 
|
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 <[hidden email]> 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.html > > 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 <[hidden email]> wrote: >>> >>> On Sun, 26 May 2013, [hidden email] 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 ]! >>>> >>>> >>>> >>> >> >> > |
Re: cannotInterpret: MessageCatchingProxy (was: The Trunk: Kernel-cmm.760.mcz)
|
|
On 27 May 2013 04:09, Chris Muller <[hidden email]> 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 <[hidden email]> 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.html >> >> 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 <[hidden email]> wrote: >>>> >>>> On Sun, 26 May 2013, [hidden email] 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 ]! >>>>> >>>>> >>>>> >>>> >>> >>> >> -- Best regards, Igor Stasenko. |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |