2014-05-22 20:37 GMT+02:00 Esteban A. Maringolo <emaringolo@gmail.com>:
2014-05-22 13:06 GMT-03:00 Camille Teruel <camille.teruel@gmail.com>:
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.
Funny thing is that Glorp proxies materialize the referenced object when they receive #yourself
- 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.
One thing is a Proxy that ALWAYS sits in between the real object and its consumer forwarding messages or doing any other instrumentation, and a different thing is a Stub which once materialized replaces all references to the proxy with references to the new object (#becomeForward:) and then vanishes (GCed).
Having proxies in hashed collections can get very tricky if the hash of the proxy/stub is different from the hash of the materialized object.
yes exactly That is why in Ghost, you can choose what to intercept because it is application dependent Luc
Esteban A. Maringolo