W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2011

RE: What type should .findAll return

From: Travis Leithead <travis.leithead@microsoft.com>
Date: Tue, 15 Nov 2011 05:10:32 +0000
To: Allen Wirfs-Brock <allen@wirfs-brock.com>, Yehuda Katz <wycats@gmail.com>
CC: Brendan Eich <brendan@mozilla.org>, Rick Waldron <waldron.rick@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Boris Zbarsky <bzbarsky@mit.edu>, "public-script-coord@w3.org" <public-script-coord@w3.org>, public-webapps <public-webapps@w3.org>
Message-ID: <9768D477C67135458BF978A45BCF9B38381A0EDF@TK5EX14MBXW603.wingroup.windeploy.ntdev.microsoft.com>
From: Allen Wirfs-Brock [mailto:allen@wirfs-brock.com] 
Sent: Monday, November 14, 2011 6:12 PM
> For right now, there are two ways you could quickly go that don't conflict with ES5.1 at all:
> 1) you can specify that .findAll returns a plain vanilla ECMAScript Array object.
> 2) you can define a new kind of host object that is a close approximation of a real ECMAScript Array object.  Such an object could indirectly inherit from Array.prototype, over-ride some inherited methods (such as concat and filter), and define additional DOM related methods.  However, its [[Class]] may not be "Array" and anything in the ES spec that requires [[Class]]==="Array" (such as Array.isArray) won't recognize it as an anything special.

This might be my simplified view of things, but have we just circled back around to the two definitions that Cameron already has in WebIDL [1]?
* 3.9.18 Sequences - sequence<T> are the corollary of #1 above (plain-old JS arrays)
* 3.9.19 Arrays - T[] are the corollary of #2 above; array-like and even are participate in the Array.prototype chain. 

In section 4.2.20, the following note outlines the difference between the so-called platform array object and a vanilla JS array:

"Platform array objects differ from Array objects in the following ways: 
" - they are never sparse
" - their elements are always data properties
" - an ECMAScript-to-IDL value conversion is always performed when storing an element
" - their internal [[Class]] property value is different
" - their internal [[Extensible]] property value is always true

Can we pick one of these as a starting point for .find()/.findAll()? For consistency with other DOM APIs, I personally see the platform array object as the way forward.

[1] http://dev.w3.org/2006/webapi/WebIDL/#idl-sequence
Received on Tuesday, 15 November 2011 05:11:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:04 UTC