- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Mon, 31 Oct 2011 06:05:15 +1100
- To: Cameron McCormack <cam@mcc.id.au>
- CC: Alex Russell <slightlyoff@google.com>, Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>, Yehuda Katz <wycats@gmail.com>, John Resig <jeresig@gmail.com>, Paul Irish <paulirish@google.com>, Lachlan Hunt <lachlan.hunt@lachy.id.au>
On 30/10/11 2:28 PM, Cameron McCormack wrote: > On 20/10/11 3:50 AM, Alex Russell wrote: >> I strongly agree that it should be an Array *type*, but I think just >> returning a plain Array is the wrong resolution to our NodeList >> problem. WebIDL should specify that DOM List types *are* Array types. >> It's insane that we even have a NodeList type which isn't a real array >> at all. Adding a parallel system when we could just fix the one we >> have (and preserve the value of a separate prototype for extension) is >> wonky to me. >> >> That said, I'd *also* support the ability to have some sort of >> decorator mechanism before return on .find() or a way to re-route the >> prototype of the returned Array. >> >> +heycam to debate this point. > > Late replying here again, apologies, but I agree with others who say > that an actual Array object should be returned from this new API given > that it is not meant to be live. What benefit is there from returning > a NodeList? > > I think it's already been said, but if StaticNodeList (or whatever) inherits from Array then it receives array methods plus it can still have .item() for people who are assuming it is like NodeList. Sean
Received on Sunday, 30 October 2011 19:05:56 UTC