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

Reply via email to