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
