Re: Notification for new navigation timing entries

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?


Received on Thursday, 12 February 2015 22:29:48 UTC