Hi Tom, I agree with you. The remaining issue is to be sure to capture all surface syntax that will exist in the spec that will be released with proxies, because we won't be able to add trap for them afterward. This is currently the case (in my opinion), but some kind of reminder should mention that in the proxy proposal in my opinion, to make sure that the risk isn't taken to forget something. If a new surface syntax is added, I agree with what you said: a proxy should raise an error.
Thanks for your response, David Le 24/01/2011 21:00, Tom Van Cutsem a écrit : > Hi David, > > Your questions are very relevant, and we did consider some of these > issues. They are part of the reason why we split the traps into > "fundamental" and "derived" traps, and why we specified that "derived" > traps have a default behavior (in terms of the fundamental traps). > That at least gives us the flexibility to easily add new derived traps. > > Adding new fundamental traps is hard, but no harder than adding the - > presumably - new surface syntax and semantics that will trigger the > trap. Let's assume that a new "foo" operator is added that would > trigger a new fundamental "foo" trap. Since the proxies spec doesn't > enforce that handler objects are complete (they are allowed to omit > traps), existing proxies will work fine as long as user code does not > use the new "foo" operator. If it does, the program will terminate > with an error, but that seems to me to be strictly better behavior > than silently ignoring the "foo" operator. > > Cheers, > Tom > > 2011/1/22 Mark S. Miller <erig...@google.com <mailto:erig...@google.com>> > > On Sat, Jan 22, 2011 at 4:20 AM, David Bruant > <bru...@enseirb-matmeca.fr <mailto:bru...@enseirb-matmeca.fr>> wrote: > > Hi, > > Thanks to yours answers I understand now that I had a wrong > idea of > proxies. > > I understood proxies as "regular objects + 'event' handlers". > I thought > that you could assign properties to a proxy as you do with an > object and > that right before the assignment, your defineProperty (or get or > anything) handler method was called. I actually had the vision > of the > forwarding handler. > > I understand now that proxies aren't regular object which life > (get/set/defineProperty/delete...) triggers behavior. Proxies are > "semanticless" objects for which ALL the semantics HAS TO be > defined > thanks to the handler methods. Hence the importance of > defining all > traps (at least the fundamental ones). Hence the > ForwardingHandler as a > first idea. Hence the host objects emulation. Hence the fix > behavior. > > I need to think more about it (writing the doc will certainly > help), > however, I think that my initial point remains. If people use > proxies > with the first specified handler API (when it is released), it may > become impossible to increase the number of fundamental traps > without > risking to break existing code. Consequently, this won't be done, > consequently, the handler API is very likely to be scarved in > stone as > the spec is released. > I need to come back with a better proof and examples, but > meanwhile, > here are a couple of questions that could solve the issue: > > > Hi David, these are good questions. Answering only for myself: > > > > - Could other handler method be created after the release of > the first > spec specifying it? (if not, would you have some proof/deep > reason for > it not to be so?) > > - If so, do you agree that there exists a risk to break > existing code at > some point and so not being able to extend the handler API as > a consequence? > - If so, is it a risk you care about or are willing to take? > > > If the new trap is truly fundamental, in the sense that there is > no coherent default behavior to fall back to that would be defined > in terms of the remaining traps, then we would indeed be > constrained from adding it. However, any enhancement to > EcmaScript's core semantics has to somehow rationalize the > existing semantics as embedded into the enhanced semantics. Thus, > default behavior of any new almost-fundamental traps could > correspond to the enhanced semantics attributed to old objects > coded before the semantics was enhanced. > > So I think the issue you raise is real but I'm not too worried. > Several proposed enhancements to EcmaScript semantics with an > effect on proxies have been considered since proxies were > originally accepted as a proposal. As far as I remember, when > these enhancements suggested new traps, they only ever suggested > new derived traps. But I may be forgetting a counter-example. > > I think this answers all three of your questions. > > > > > Thanks again for all your answers, > > David > > > > > -- > Cheers, > --MarkM > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
