2014-05-22 20:37 GMT+02:00 Esteban A. Maringolo <emaring...@gmail.com>:
> 2014-05-22 13:06 GMT-03:00 Camille Teruel <camille.ter...@gmail.com>: > > > > On 22 mai 2014, at 11:54, stepharo <steph...@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 > >
