On Feb 15, 2009, at 12:14 PM, Allen Wirfs-Brock wrote:
-----Original Message-----
From: Brendan Eich [mailto:[email protected]]
Sent: Sunday, February 15, 2009 10:43 AM
...
What happens, if the [[DefineOwnProperty]] is used to create an
accessor
property of an array instance whose name is an array index. I've
thought of
three possibilities:
...
Implementations want 3, so do users. SpiderMonkey js shell sessions:
...
Existing practice favors 3 over 1. That's decisive in my opinion
(getters and setters are a de-facto standard ES3.1 is codifying and
improving).
It would be nice to have some concrete examples to backup the
assertions in the first quote above. Does anyone know of actual use
cases or concrete examples where users have exploited this
capability in interesting ways.
http://mxr.mozilla.org/mozilla-central/source/js/narcissus/jsexec.js#666
http://mxr.mozilla.org/mozilla-central/source/js/narcissus/jsexec.js#869
I know of other array workalikes and proxies built this way; I'll post
source links if I can find any.
Now I hope you're gonna quibble about what is "interesting"!
Similarly, can we be more concrete about why implementers would
favor #3 (other than that it would make it easier for existing
implementations that already do #3 to support ES3.1. That is a
reasonable consideration what I acknowledge).
Implementation hardship is minor: all array implementations that
optimize for the dense case have to fall back on a more Object-like
sparse case (hash table), or mix in the latter to the former
implementation somehow. Defining an accessor simply triggers that
fallback or hybridization, as do sparseness and possibly other criteria.
I can think of assorted ways that #1 might benefit implementers who
are interested in various optimizations of arrays. It's less obvious
to me that #1 would be detrimental to implementations and #3 would
be beneficial.
The main point is users, not implementors. Implementation hardship is
a consideration, but secondary and (from experience, and from looking
at other open source implementations) not a problem in this case.
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss