Re: On ES Harmony proxies extensibility
Re. the cryptic error messages when triggering missing derived or
fundamental traps: is there any reason why an engine can't create
understandable error messages for these cases?
An error message such as non-callable defineProperty trap on proxy would
more readily identify the problem than defineProperty is not a function.
2011/1/24 Tom Van Cutsem tomvc...@gmail.com
I think there would be a couple of differences between a noop-handler and a
forwarder-to-an-empty-object.
For one: defining a property on a forwarder-to-an-empty-object would
actually define the property on the empty object. AIUI, the noop handler
would silently absorb the assignment. Fixing would also be very different. I
think forwarding-to-an-empty-object would probably lead to the most
intuitive behavior. toString() would also work as expected when forwarding
to an empty object.
One could define a helper function along the lines of:
Proxy.createEmptyHandler = function(proto) {
proto = proto || null; // maybe the default should be Object.prototype so
that toString() works as expected
return new Proxy.Handler(Object.create(proto));
}
I'm not sure whether this is sufficiently convenient to be worth
standardizing though.
2011/1/22 Dave Herman dher...@mozilla.com
Not sure; I'll think about it. Though abstracting
Proxy.Handler(Object.create(null, {})) might in fact be a worthwhile
convenience.
Dave
Mark S. Miller erig...@google.com wrote:
On Fri, Jan 21, 2011 at 2:45 PM, David Herman dher...@mozilla.com
wrote:
Should we have a no-op or sink standard handler too?
I think so, yes. Especially since you can use that to build one up
that
implements just the other traps you want to implement, and let the
others
fail soft.
How would it be different from
new Proxy.Handler(Object.create(null, {}))
?
Or, depending on how soft you want to fail
new Proxy.Handler(null)
?
If there is a useful difference, I have no objection.
Dave
--
Cheers,
--MarkM
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
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
Re: On ES Harmony proxies extensibility
I think there would be a couple of differences between a noop-handler and a
forwarder-to-an-empty-object.
For one: defining a property on a forwarder-to-an-empty-object would
actually define the property on the empty object. AIUI, the noop handler
would silently absorb the assignment. Fixing would also be very different. I
think forwarding-to-an-empty-object would probably lead to the most
intuitive behavior. toString() would also work as expected when forwarding
to an empty object.
One could define a helper function along the lines of:
Proxy.createEmptyHandler = function(proto) {
proto = proto || null; // maybe the default should be Object.prototype so
that toString() works as expected
return new Proxy.Handler(Object.create(proto));
}
I'm not sure whether this is sufficiently convenient to be worth
standardizing though.
2011/1/22 Dave Herman dher...@mozilla.com
Not sure; I'll think about it. Though abstracting
Proxy.Handler(Object.create(null, {})) might in fact be a worthwhile
convenience.
Dave
Mark S. Miller erig...@google.com wrote:
On Fri, Jan 21, 2011 at 2:45 PM, David Herman dher...@mozilla.com
wrote:
Should we have a no-op or sink standard handler too?
I think so, yes. Especially since you can use that to build one up
that
implements just the other traps you want to implement, and let the
others
fail soft.
How would it be different from
new Proxy.Handler(Object.create(null, {}))
?
Or, depending on how soft you want to fail
new Proxy.Handler(null)
?
If there is a useful difference, I have no objection.
Dave
--
Cheers,
--MarkM
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
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
Re: On ES Harmony proxies extensibility (corrected)
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.frwrote: 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
Re: On ES Harmony proxies extensibility (corrected)
On Sat, Jan 22, 2011 at 4:20 AM, David Bruant bru...@enseirb-matmeca.frwrote: 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
Re: On ES Harmony proxies extensibility
Hi David,
What does exactly not be trapped mean? If you define a property on a proxy
object, the defineProperty trap of the handler is the only method with which
that operation can succeed. If defineProperty doesn't exist you want us to just
ignore the operation?
I think this approach has some pretty several problems. If a programmer writes
down 6 of the 7 mandatory traps and forgets one, it will be very hard to debug
why the proxy doesn't work as expected. Corresponding operations just
disappearing in a black hole is not very intuitive.
I am not completely dismissing your concerns. We are using proxies internally
in Firefox and most people I have seen use them for the first time make exactly
the mistake your code does below: not implement all the mandatory traps. The
resulting error messages are not very intuitive, but they are a reflection of
the language semantics behind the scene.
For some specific reasons Mark can explain better than me the spec doesn't want
the implementation to verify the existence of all 7 mandatory traps, so thats
not really an option either.
We have previously discussed adding standard handlers to the specification,
i.e. an NoopHandler and a ForwardingHandler. You can delegate to these from
your handler to get the desired default behavior. I think this is the best of
the someone poor choices we have. It catches accidental trap omissions, but
still allows you to leave them out as long you pick a default behavior (and it
doesn't force a specific default behavior down people's throat).
Andreas
On Jan 21, 2011, at 8:43 AM, Mark S. Miller wrote:
Hi David, I'm forwarding your message to es-discuss as it has no direct
relevance to ES5 per se.
All, please reply only on es-discuss.
-- Forwarded message --
From: David Bruant bru...@enseirb-matmeca.fr
Date: Fri, Jan 21, 2011 at 3:08 AM
Subject: On ES Harmony proxies extensibility
To: es5-disc...@mozilla.org
Hi,
Working on writing the MDN doc for ES Harmony proxies
(https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Proxy),
I've studied the proxies and would like to provide some feedback.
My main concern in the proposal (and its current implementation on FF4b9) is
the following sentence: handler is an object that at minimum implements the
following API (7 functions). At first, I didn't understand why and then I
have tried the following :
var p = Proxy.create({get: function(proxy, name) {
return 'Hello '+ name;
}
});
Object.defineProperty(p, 'a',{value:1});
In FF4b9, this code triggers an error : defineProperty is not a function. I
interpret this as: the proxy traps the defineProperty call, then calls
handler.defineProperty which is undefined.
It gets a bit more weird when a derived trap is called. If undefined in the
handler, the default behavior is called. This behavior uses one of the
fundamental trap (by definition of derived trap). If this fundamental trap
isn't implemented in the handler, an error is thrown about the fundamental
trap which is not very intuitive. This is more of an implementation concern,
but it could be given as an advice for future implementation.
Since proxies trap all traps (fundamental and derived), all fundamental
traps need a handler method. I think that it can be the cause of a problem
for the Proxy standard extensibility:
Let's assume that, at some point, the Proxy proposal gets standardized. It
will have a well-defined set of fundamental traps and of derived traps.
People are going to write applications with them.They are going to implement
the 7 fundamental traps. This is code in the wild.
Let's assume (and this assumption is the one to discuss, I think) that the
TC-39 comittee wishes to extend the number of fundamental traps with a
fundamental trap 'FT'. This wish won't be able to be fulfilled, because
proxies will be already implemented and used. These proxies handler will
implement the 7 fundamental traps (not the 8th one) and consequently executed
on an ES engine with support of the 8th trap, it will trigger some sort of
error (FT is not a function) each time the behavior trapped by FT happens.
Potentially breaking existing code, adding FT will be impossible.
My point is that as soon as Proxies will be standardized, it will become
impossible to add fundamental traps without either breaking existing code or
becoming inconsistent.
In my opinion, the extensibility problem is due to the fact that all traps
are trapped by default in proxies regardless if the user wants it or not.
Please allow me an analogy with DOM events. I see proxy traps as events on
ECMAScript objects. When in the code a delete happens, a /delete/ event
happens, it is trapped and the delete handler function is called like a event
handler for a DOMEventListener.
Capturing all
Re: On ES Harmony proxies extensibility
We have previously discussed adding standard handlers to the specification, i.e. an NoopHandler and a ForwardingHandler. Yes, and Tom and Mark have been working on this and making good progress. They have a forwarding handler mostly worked out, which we discussed yesterday at the face-to-face meeting. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On ES Harmony proxies extensibility
Should we have a no-op or sink standard handler too? I think so, yes. Especially since you can use that to build one up that implements just the other traps you want to implement, and let the others fail soft. Dave ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: On ES Harmony proxies extensibility
Not sure; I'll think about it. Though abstracting
Proxy.Handler(Object.create(null, {})) might in fact be a worthwhile
convenience.
Dave
Mark S. Miller erig...@google.com wrote:
On Fri, Jan 21, 2011 at 2:45 PM, David Herman dher...@mozilla.com
wrote:
Should we have a no-op or sink standard handler too?
I think so, yes. Especially since you can use that to build one up
that
implements just the other traps you want to implement, and let the
others
fail soft.
How would it be different from
new Proxy.Handler(Object.create(null, {}))
?
Or, depending on how soft you want to fail
new Proxy.Handler(null)
?
If there is a useful difference, I have no objection.
Dave
--
Cheers,
--MarkM
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
