[Vm-dev] Re: [Pharo-dev] Proxy DNU vs CannotInterpret. (Ghost
bera.clement at gmail.com
Mon Feb 15 19:46:11 UTC 2016
2016-02-15 19:34 GMT+01:00 Eliot Miranda <eliot.miranda at gmail.com>:
> 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.
The #class primitive bytecode is not used in Pharo to avoid this kind of
It is indeed possible to add a setting in Opal compiler not to compile #==
using the inlined selector to avoid issues there too. However, even in
proxies, it may make sense to have this inlined selector.
>> 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...
More information about the Vm-dev