but we're now talking about a pure ECMAScript function so DOM conventions shouldn't be applicable. But consistency with common JavaScript practices should be.
If you want to apply it to an already allocated array then making it method on Array.prototype would be a more internally consistent way to do it. Although, I also a bit partial to the string based formulation and I assume that relatively small string values should be fairly efficient to allocated. In either case, it does sound like premature optimization relative to everything else that is likely to beging on the the JS code that actually uses these random values. Allen On Feb 14, 2011, at 4:47 PM, Brendan Eich wrote: > On Feb 14, 2011, at 3:03 PM, Allen Wirfs-Brock wrote: > >> And why overwrite the elements of an existing array? Why not just creating >> a new Array and use the argument to specify the desired length? > > Just to respond to this, I believe the reusable buffer is an optimization > (premature? perhaps not for those JS VMs that lack super-fast generational > GC) to allow the API user to amortize allocation overhead across many calls > to getRandomValues. Of course, with a fast enough GC or few enough calls, > this optimization doesn't matter. > > The IDL's use of an array inout parameter also supports efficient bindings > for languages with stack allocation, which is a non-trivial win in C and C++ > not only compared to malloc performance-wise, but also for automated cleanup > (vs. intrinsic cost of free, plus on some OSes, "which free do I call"?). > > /be _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
