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: - 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? Thanks again for all your answers, David _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
