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
