Well, the main drawback is that you'll not be able to trap any messages implemented by DNUProxy, because as they are implemented, they are understood.

Also, the idea of Ghost was not only to use cannot interpret, but to provide a library that allowed to proxy objects as well as methods and classes.

Finally, I'm curious about the performance difference... because the interpreter code handling DNU and cannot interpret is not much different... Maybe the JIT is not handling it (because nobody proposed it before)?

Guille

On 02/15/2016 03:11 PM, Denis Kudriashov wrote:
I compared doesNotUnderstand: vs��cannotInterpret:��versions of proxies.

DNUProxy>>doesNotUnderstand: aMessage��
lastMessage := aMessage.
^'from DNU proxy'

CannotInterpretProxy>>cannotInterpret: aMessage��
lastMessage := aMessage.
^'from cannot interpret proxy'


And DNU proxy works 2 times faster then #cannotInterpret proxy.

[proxy someMessage] benchFor: 2 seconds.

DNU:
��"a BenchmarkResult(22,377,669 iterations in 2 seconds. 11,188,835 per second)"

CannotInterpet:
��"a BenchmarkResult(13,148,735 iterations in 2 seconds 2 milliseconds.��6,567,800 per second)

Also DNU version is much more easy to explain.��

So why Ghost uses #cannotInterpret for proxies? (after reading Ghost paper I can't understand this).
Naked proxy can be easily done by setting superclass to nil:

ProtoObject subclass: #DNUProxy
instanceVariableNames: ''
classVariableNames: ''
package: 'DNUProxy'.
DNUProxy superclass: nil

��