Discuss
  • On ES Harmony proxies extensibility (corrected)

On ES Harmony proxies extensibility (corrected)

# David Bruant (15 years ago)

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,

# Mark S. Miller (15 years ago)

On Sat, Jan 22, 2011 at 4:20 AM, David Bruant <bruant at 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.

# Tom Van Cutsem (15 years ago)

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 <erights at google.com>

# David Bruant (15 years ago)

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 :