- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Thu, 12 Feb 2015 17:29:12 -0500
- To: Nat Duca <nduca@google.com>
- CC: Ilya Grigorik <igrigorik@google.com>, Philippe Le Hegaret <plh@w3.org>, public-web-perf <public-web-perf@w3.org>, Eli Perelman <eperelman@mozilla.com>
On 2/12/15 5:20 PM, Nat Duca wrote: > The design goal I had in mind for this was to avoid construction of > PerformanceEntry objects until you actually needed them. Accessing these > entries is quite slow to just buffering them. Here's a question: why? Note that for cases when the implementation doesn't immediately reify the PerformanceEntry objects, it ends up needing to cache the reified versions and whatnot, right? > That is, it was intentional to not have forEach and other things on > these arrays. Given a length and indexed getter, why not? I mean, the caller can clearly just walk along the whole list reifying the PerformanceEntry objects anyway... > This is like NodeList --- QuerySelectorAll gives back a > ton of stuff, but you have to work to get the actual contents. NodeList is getting [ArrayClass] as soon as the concat() web compat issues it runs to are fixed. And the replacement API for querySelectorAll() (find() or whatever it's called today) returns an ES array subclass, fwiw. > So basically, I actually think its bad to support forEach on the object > without some additional work.... Then why are you including a length and indexed getter? -Boris
Received on Thursday, 12 February 2015 22:29:48 UTC