On Sat, Oct 29, 2011 at 8:28 PM, Cameron McCormack <c...@mcc.id.au> 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?
If it's a NodeList (or something else that *subclasses* Array) we can do fun things like add .find to it, which returns the sorted union of calling .find on all the elements within it. Returning a plain Array doesn't let us do that. ~TJ
