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> > On Sat, Jan 22, 2011 at 4:20 AM, David Bruant > <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 > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
