[Vm-dev] Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost related)

[stepharo]

In pharo 60 we will revisit and shrink protoObject.

Stef

Le 15/2/16 19:34, Eliot Miranda a écrit :
>   
>
>
> Hi Stef,
>
> On Mon, Feb 15, 2016 at 8:18 AM, stepharo <stepharo at free.fr 
> <mailto:stepharo at free.fr>> wrote:
>
>     Hi eliot
>
>     I think that the difference is really what guillermo explained.
>     With DNU you can only trapped methods that are not defined while
>     if you want to implement true proxy you do not want holes.
>     I think that also with DNU proxy there were some limits realyed to
>     classe but I do not remember.
>
>
> As far as the VM goes, there is /one/ minor issue with special 
> selector #== and #class (*).  But the real issue is that ProtoObject 
> implements far too much protocol.  If one creates a class that 
> inherits from nil all it needs to do is implement doersNotUnderstand: 
> and it will catch every message (*).  For this to work the debugger 
> and basic inspectors must use the mirror primitives otherwise there 
> will be infinite recursion of MNUs.
>
> Now the issue with special selector #== and #class is that these 
> bytecodes are specified as no lookup.  So if one uses bytecodes 182 
> (#==) or 199 (#class) these operate without sending messages and will 
> compare the object or answer the object's class without sending 
> #doesNotUnderstand:.
>
> In the VW VM I added a flag so one could turn this behaviour off, and 
> that's certainly easy to do in our VM. Another approach is to have the 
> bytecode compiler not send these.
>
> But given our VM it is certainly possible to use doesNotUnderstand: 
> proxies, using a much slimmer class than ProtoObject.  In fact a good 
> project would be to try and shrink ProtoObject until it provides the 
> minimum, which would be a #doesNotUnderstand: method that raises an 
> error that reminds the programmer that they need to implement their 
> own doesNotUnderstand: handler in subclasses of ProtoObject.
>
>
>     Stef
>
>     Le 15/2/16 16:06, Eliot Miranda a écrit :
>>     Hi Denis,
>>
>>     On Feb 15, 2016, at 6:53 AM, Denis Kudriashov
>>     <dionisiydk at gmail.com <mailto:dionisiydk at gmail.com>> wrote:
>>
>>>
>>>     2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck
>>>     <marianopeck at gmail.com <mailto:marianopeck at gmail.com>>:
>>>
>>>         As far as I can remember (this was about 4 years ago) The
>>>         use of #cannotInterpret: was the only way to be able to
>>>         intercept everything without breaking the system.
>>>         Subclassing from ProtoObject make your proxy to understand
>>>         some messages. Subclassing from nil was technically
>>>         possible, but I found out the system would simply crash as
>>>         it didn't know at all how to handle other subclasses of nil.
>>>         Even with the debugging support I added as you can read in
>>>         the paper. Maybe things have changed.
>>>
>>>         If subclassing from nil does not break the system and you
>>>         can still inspect, debug proxies, then sure, you can give a
>>>         try to Ghost using #dnu rather than #cannotInterpret:. In
>>>         fact, I would like to have a dnu-based approeach that is as
>>>         reliable as it was #cannotInterpret: in the sense of how
>>>         much I can intercept. With #cannotInterpret I could trap
>>>         EVERYTHING (everything but #==) and then decide what to do.
>>>         Subclassing from nil would get you there too if you make it
>>>         work.
>>>
>>>
>>>     Actually I already implemented it many yeas ago for Mocketry.
>>>     But subclassing from nil works correctly only in VW. I got
>>>     problems when porting it to Squeak (at that time).
>>>     Now I want to give DNU another chance. It will simplify logic
>>>     very much. It will remove strange hierarchy of proxies which is
>>>     needed for trick but raises many questions.
>>
>>     There is no reason in principle why Squeak/Pharo should not be
>>     able to use MNU proxies in the same way as VW.  The key is to use
>>     the mirror primitives in basic inspectors that are used to
>>     inspect the proxies and in the debugger to simulate code.
>>      Without the mirror primitives many sends to a proxy are likely
>>     to create an infinite recursion.  As yet we don't have a robust
>>     low space handler that catches infinite recursion so debugging
>>     can be frustrating.  But we can work on this. IMO the MNU
>>     approach is to be preferred.
>
>
>
>
> -- 
> _,,,^..^,,,_
> best, Eliot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160324/01a6c9e2/attachment-0001.htm