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

Eliot Miranda eliot.miranda at gmail.com
Mon Feb 15 18:34:33 UTC 2016


Hi Stef,

On Mon, Feb 15, 2016 at 8:18 AM, stepharo <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>
> dionisiydk at gmail.com> wrote:
>
>
> 2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck < <marianopeck at gmail.com>
> 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/20160215/b0d9dac4/attachment.htm


More information about the Vm-dev mailing list