On 22 mai 2014, at 11:54, stepharo <stepharo@free.fr> wrote:

>
>> In general, we should think about if is would make sense that the language comes with
>> a good proxy model by default.
>
> + 1
> We should do that with Camille.

Yes.
Now the problem is to agree on what is a "good model".
There is many use cases for proxies and they come with their own models and problems.

Here are some requirements I can think of:

- Uniformity: all objects can be wrapped, even special ones (it's a technicality but it's still important)
- Interception of all message: currently we cannot intercept #== and optimized control-flow messages like #ifTrue:ifFalse #to:do:, #whileTrue:, etc...
- Encapsulation (a.k.a the self problem): avoid leaking of references to the target. E.g. "aProxy yourself" should return the proxy not the target.
- Behavioral intercession: Not everything is a message send. What other events do we want to intercept? IV access is a must-have for me.
- Composition: Wrapping a proxy with another one should work as expected, i.e. applying both policies in order.
- Performances: intercepting message sends is slow, intercepting iv accesses is even worse (relying on code instrumentation). We would need VM support.
- Security: It shouldn't be possible to by-pass or corrupt a proxy policy.
- Delimited replacement: Ensure that a proxy is always used in place of its target throughout the processing of a message send, no matter the alias used (that is not necessarily "self"). Think about a read-only proxy for example.

Right now, to intercept messages we have to rely on #cannotInterpret: hack

. To intercept iv access or other events we have to rely on code instrumentation and delegation.

It would be easier if the VM would allow to create an object that controls its own interpretation (via a metaobject that defines a MOP for example). Such an object should at least be able to specify its message lookup and how to reads and writes IVs.
And optionally:
- how it sends messages

- how it resolves other variables (temporaries, arguments, globals, class variables)
- how it resolves literals
- how it executes primitives (because else the VM may cry)
- how it is assigned to a variable or passed in a message (to control static/dynamic aliasing respectively)

- ... many others ...
With such objects (+ operating by delegation instead of forwarding) we can solve most of the requirements listed above (well except performant delimited replacement).
All that to say that it is not easy...

>> (this way we would avoid that everyone creates one that is not completely working)
>
>