Ahhh and the difference with MethodWrappers (at least with the implementation that is in the Pharo image)
- MethodWrapper intercepts both things: 1) messages sent to the object (as if it were a compiled method), and 2) method execution MyClass at: #foo put: MyMethodWrapper. (MyClass methodAt: #foo) literals. --->> 1) MyClass new foo ---->> 2) 1) is done using #dnu and 2) using #run:with:in: the problem is that the method wrapper is a subclass from Object, so there are 375 methods (Object methodDict size) that will be understood by the proxy itself instead of trapping the message. Ok, you can subclass from ProtoObject, that would be better (ProtoObject methodDict size -> 38 ). But still, even subclassing from nil, it is not stratified. (MyClass methodAt: #foo) blahBlah will try to trap the message instead of raise a MNU. I don't know what do you need for your case, if both things 1) and 2). If it is only 2) then there is few advantages with our implemetnation. If you need both, then yes, I would take a look. cheers mariano On Thu, May 5, 2011 at 9:59 AM, Mariano Martinez Peck <[email protected] > wrote: > > > On Thu, May 5, 2011 at 4:30 AM, Igor Stasenko <[email protected]> wrote: > >> On 5 May 2011 01:59, Johan Fabry <[email protected]> wrote: >> > >> > On 04 May 2011, at 17:30, Stéphane Ducasse wrote: >> > >> >> >> >> mariano got a really nice proxy model based on the stratified proxy of >> igor (which is in 1.3). >> > >> > >> > Question: could this be used for PHANtom? We are now using >> Methodwrappers but there are some issues (fixed in PHANtom). Mariano, Igor, >> can you explain the advantages of your model wrt methodwrappers? >> > >> >> Sorry i'm not familiar with methodwrappers. >> >> The basic model is separation of proxy and handler. Proxy acts only as >> a message trap, >> while handler is actually responsible for handling messages trapped by >> proxy. >> >> Mariano builds on top of that, because he wants to replace classes >> and/or methods with proxies, >> and this requires a special handling (class proxy should obey >> VM-specific Behavior format, >> and method proxy should implement #run:in:as: when installed in method >> dictionary ). >> >> So, i guess that proxies which representing compiled methods could act >> similar to method wrappers. >> But of course you still have to implement all intall/deinstall >> management et al.. >> >> The only advantage of new proxies comparing to usual proxies based on >> #DNU pattern that >> they guarantee a clear separation between meta-levels, i.e. even if >> you send #doesNotUnderstand: >> message to a proxy, this message will be trapped and handled by >> handler as any other. >> >> > > Yes, and the cool thing is that proxies can intercept ALL messages, not > only those that are not understood. Hence, you don't need to subclass from > ProtoObject or nil. > In addition (I think, I didn't measure) that they are faster because they > don't need to the method lookup until getting to the dnu..but I am not sure > about this last one. > > Another problem with the DNU is what Igor say, you are mixing both things: > error handling and message trapping. So...when a proxy receives DNU, how do > you know if it was a real dnu or because it needs to trap the message? > > Implementing method wrappers on top of such proxies is a matter of 5 > minutes as much as I can see. In fact, in the paper I "implement" method > wrappers as an example. > > You can take a look by > > Gofer new > squeaksource: 'Marea'; > package: 'GhostProxies'; > package: 'GhostProxiesTests'; > load. > > But remember it is just a prototype ;) > > The paper is almost finish... > > cheers > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com
