On Dec 7, 2009, at 4:11 PM, Tom Van Cutsem wrote:
Dear all,
Over the past few weeks, MarkM and myself have been working on a
proposal for catch-alls for ES-Harmony based on proxies. I just
uploaded a strawman proposal to the wiki:
http://wiki.ecmascript.org/doku.php?id=strawman:proxies
Hi Tom, great to see this proposal. I took the liberty of making a few
small edits; hope they're ok. I like the stratification and the ab-
initio nature of the design -- the last seems to me to be a crucial
improvement over past proposals, which may help overcome the "climbing
the meta ladder" objection.
Some initial comments, pruned to avoid restating others' comments:
1. This proposal obligates the catch-all implementor to delegate to
any prototype object in has and get, to include unshadowed prototype
properties in enumerate, to shadow if p in receiver.[[Prototype]] in
put, and to do nothing for delete proxy.p if !proxy.hasOwnProperty(p).
In general, handler writers have to implement standard prototype-based
delegation if it is desired. This is probably the right thing, but I
wonder if you considered the alternative where prototype delegation is
handled "by the spec" or "by the runtime" and the proxy is considered
"flat"?
2. The fix handler returning undefined instead of throwing explicitly
to reject a freeze, etc., attempt is a bit implicit. Falling off the
end of the function due to a forgetten or bungled return will do this.
Ok, let's say the programmer will test and fix the bug.
But more significant: could there be a useful default denoted by
returning undefined or falling off the end of the fix function? An
alternative interpretation would be an empty frozen object. This has
symmetry with undefined passed (or no actual argument supplied) to
Object.create. It's a minor comment for sure.
3. Mozilla's wrappers (proxies, membranes), which we pioneered for
security purposes (e.g. for DOM inspectors where privileged JS is
interacting with web content objects) and which have been copied in
other browsers (at least WebKit), implement === by unwrapping, so two
wrappers for the same object are === with that object, and with each
other.
The proxies proposal does not have an unwrapped object, although
super? is similar. Later in the proposal, you write "meta-level code
will ‘see’ the proxy rather than the object it represents." This
sounds more like wrappers as we use them -- there is always a wrapped
object and its proxy or wrapper.
The alternative of not trapping === is a leaky abstraction that
inevitably breaks some programmers' expectations. Our early wrappers
did not hook ===, but eventually we settled on the unwrap-before-===
behavior based on testing.
This is a use-case I wanted to bring to your attention (Mike Samuel
raised it in his reply by suggesting a Proxy.proxies predicate; his
[[Class]] question also gets to the broader issue of transparency vs.
leaky proxy abstractions). Our wrapper experience suggests allowing
=== to be hooked in a constrained way, for certain kinds of proxies.
It could be that this use-case can't be served by a standardized,
general proxy/catch-all proposal, and must be done under the hood and
outside of the ES spec.
4. The [[Get]] versus [[Invoke]] rationale: indeed performance is a
concern, but existing engines also specialize callee-computation
distinctly from get-value, in order to optimize away Reference types.
The ES specs so far do not, instead using the internal Reference type
to delay GetValue so as to bind |this| to the Reference base when
computing a callee and its receiver as part of evaluating a call
expression.
I think it is an open question whether a future spec, especially one
using a definitional interpreter, will stick to References. If we end
up making the distinction that all practical implementations already
make, between get-as-part-of-callee-computation and all other get-
value "gets", then I don't think this rationale is so strong.
In general over-coupling to ES5 may not help either a new Harmony-era
proposal to "get in", or to be as complete or expressive as it should
be. So a rationale based on choices or limitations of ES1-5 seems weak
to me.
Thanks again for this proposal,
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
