Can an Array have array indexed accessor properties and other curiosities??

Brendan Eich brendan at mozilla.com
Sun Feb 15 12:41:16 PST 2009


On Feb 15, 2009, at 12:14 PM, Allen Wirfs-Brock wrote:

>> -----Original Message-----
>> From: Brendan Eich [mailto:brendan at mozilla.com]
>> 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


More information about the Es-discuss mailing list