- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Thu, 12 Feb 2015 17:08:28 -0500
- To: Ilya Grigorik <igrigorik@google.com>
- CC: Philippe Le Hegaret <plh@w3.org>, public-web-perf <public-web-perf@w3.org>, Nat Duca <nduca@google.com>, Eli Perelman <eperelman@mozilla.com>
On 2/12/15 4:51 PM, Ilya Grigorik wrote: > (1) Allow buffering use cases to store the event lists BUT defer > creation of the PerformanceEntry objects until they are retrieved by the > script via the item getter. OK. Then you can't use an actual array, obviously. That's a problem if there is already deployed code that assumes this object is an array. Are there implementations shipping right now with an array here? You can almost get away with doing an [ArrayClass] thing, except for the issues around concat... but maybe those wouldn't arise in this case, or we can actually do the @@isConcatSpreadable thing or something. Not sure what the status of that being implemented in JS engines is. > Boris, Philippe: any suggestions for how to deliver that while providing > the best developer experience? FWIW, the intent behind the above IDL was > to provide: forEach support The IDL in https://docs.google.com/document/d/1fXtxtPC1Gg4PeLXI_axj6AvMTznf9X5lrj5HTyR3r3w/edit#heading=h.lmpa8rntu3jn doesn't provide that. Also doesn't provide .map(), which is something I expect people might want to use... I think just making this [ArrayClass] would probably achieve most of what you want, as long as we don't run into issues with concat(). Also, you can use an anonymous getter to avoid adding an item() thing that seems superfluous right? -Boris
Received on Thursday, 12 February 2015 22:09:03 UTC