- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 16 Feb 2011 16:02:22 -0500
On Mon, Feb 14, 2011 at 8:03 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote: > 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. > This isn't an optimization; it's simply a different design. Optimization is one underlying rationale, but not the only one. I don't think optimization is an important consideration here for crypto, since you usually don't need a lot of random data to generate a key--often on the order of a few dozen or hundred bytes. You're not reading a megabyte of data to generate a key. There can be uses for generating large blocks of randomness for non-crypto, though, of course. However, it also allows specifying the type of the data to return: whether the random data should be interpreted as 8-bit arrays, 16-bit arrays, and so on. I don't know if that's actually important (havn't seen specific use cases), but that was another rationale. I think it was also intended to avoid encoding 8-bit data in a UTF-16 string. -- Glenn Maynard
Received on Wednesday, 16 February 2011 13:02:22 UTC