On 22 mai 2014, at 22:29, Luc Fabresse <luc.fabre...@gmail.com> wrote:
> > > > 2014-05-22 19:49 GMT+02:00 Camille Teruel <camille.ter...@gmail.com>: > > On 22 mai 2014, at 19:07, Luc Fabresse <luc.fabre...@gmail.com> wrote: > >> >> >> >> >> 2014-05-22 18:06 GMT+02: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. >> >> yes sure >> >> 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 >> >> why do you call it a hack? > > Because it's a hijack a safety check of the VM. > We set the method dictionary of the proxy's class to nil (or of its > superclass if the proxy must understand some messages). > Since the VM doesn't know what to do with that, it calls #cannotInterpret: > starting the lookup in the superclass of that class. > This superclass then redefines #cannotInterpret: to hand over the message > interception to the proxy's handler... > > I know the mechanism ;-) I know you know, but there is many people on this mailing list :). It was to stress that we need three indirections (1st lookup, 2nd lookup, forward request to handler) where 1 would be enough if done at the vm side. I call it a hack but it's not pejorative. It's the best we can do without vm modification after all. > but to me it is not hack it is a clever idea that let the programmer to > decide what to do at the image side to implement crazy stuff without > modifying the VM That sure is clever and it's great to not have to modify the vm, but modifying it to support proxies worth it in my opinion. > The VM is simple (one interception hook) while it enables to capture a lot of > things. > Of course we can imagine something else at the VM side but the more code in > the VM the less flexible it will be > > >> do you consider DNU as hack too? > > Using it to implement proxies? Yes. > But in addition, DNU is bad since you can only intercept messages that are > not understood. > And you can also by-pass the message the proxy does understand by sending > directly #doesNotUnderstand: to the proxy with a specific message as argument. > > we also explained that in the Ghost paper... > that is why cannotInterpret is better but yet incompelete to capture > everything Only because of compilation optimizations. It is a real problem for certain applications. > > >> >> . To intercept iv access or other events we have to rely on code >> instrumentation and delegation. >> >> yes but I would like to investigate if cannot achieve iv interception using >> special slots > > I doubt we can since it is the target's slots that are taken into account > during compilation. > Or else every slot in the system must be special => really poor performances. > > I have no clear idea yet on that so I must have look and you are certainly > right > > Luc > >> >> 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 >> this one is possible with cannotInterpret >> you intercept and then you decide what to do and maybe execute something >> else so you control message sending > > I was talking about interception of message sending (the message the target > would have sent) not of interception of message reception (the living wage of > any proxy implementation :) ). > Like the others events, it also lies at the submethod level. > >> - 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) >> >> all of those ones are submethod level and yes Ghost stops at the object >> granularity currently >> >> - ... 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... >> >> yes but it is interesting ;-) >> and we also discuss "some parts" of that with Nick > > Great, let us know about the conclusions :) > >> >> Luc >> >> >> (this way we would avoid that everyone creates one that is not completely >> >> working) >> > >> > >> >> >> > >
