Too much and too complex, say I! ;)
I liked your previous thinking that we should just return a fresh array. And in
the interest of keeping it dead simple, let's just fix it at 32 bits -- always.
Then the question is: string, array, typed array, or binary data?
I say: let's make it typed array in the short term, but TC39 will spec it as an
array of uint32 according to the binary data spec. We will try to make the
binary data spec as backwards compatible as possible with typed arrays anyway.
So in the near term, implementors can use typed arrays, but when they have
implementations of the full binary data spec, they can change to use those.
It'll probably be a slightly backwards-incompatible change, but by keeping them
relatively API-compatible, it shouldn't make too much difference in practice.
Plus we can warn people that that change is coming.
So: Math.getRandomValues(length) or whatever you wanna call it, would just
return a fresh array.
I might also be ok with extending it so that you can pass it an optional
pre-existing array for it to mutate, for the sake of efficiency:
Math.getRandomValues(length[, uint32array[, start]]).
(The window.crypto object could just be a reference to the same
Math.getRandomValues function value.)
Dave
On Feb 16, 2011, at 4:29 PM, Allen Wirfs-Brock wrote:
> So, let's get back to the design of an actual ECMAScript API.
>
> I'll repeat a couple of initial points:
> We are now talking about a pure JavaScript API, not a DOM API so it should
> follow JavaScript conventions.
> If we want this to appear in browsers in the very near future we should
> minimize any dependencies upon other Harmony features that are not both
> totally finalized and trivial to implement (the empty set??)
>
> The first point would seem to eliminate DOM-like conventions such as pseudo
> by-ref/in-our parameters, multiple numeric data types, or dependency upon any
> host object (DOM) array like objects.
> The second would seem to preclude the use of the proposed Harmony binary
> typed arrays.
>
> In general, I don't see any particular reason why an ECMAScript array would
> be unsuitable to collecting a sequence of random numeric values. It's what
> people do today when they need to manipulate sequences of numbers.
>
> If we are using array's, the simplest API is probably a new function on the
> array construct that is a factory for Arrays fill with random numeric values:
>
> Array.randomFill= function (length){...};
>
> This would create a new array of the specified length where each element is a
> random value in some range. I propose that this range be 0..65535 as these
> are easily manipulatable (and optimizable) values that are likely to have
> some degree of optimization in all implementations. I don't really see why
> other element ranges need to be supported as they are easily constructed
> these values. However, if strong use cases (endianness??) can be made for
> the utility of natively supporting multiple element ranges then we could
> either add more functions:
> Array.randomFill8(length)
> Array.randomFill24(length)
> Array.randomFill32(length)
> or accept an optimal second parameter that specifies the desired bit width:
> Array.randomFill(length, bitWidth /*1 .. (32?, 48?, 53?) */)
>
> I would recommend keeping it simple and avoiding such non-essential tweaks.
>
> There was some (it didn't seem very serious) concerns about the cost of array
> allocation for such calls. I would point out that creating a new array is
> already the technique used in ECMAScript for most somewhat comparable
> situations such as the results of RegExp matches, the set of items deleted by
> slice, etc. Others might invoke words about the desirability of a functional
> style...
>
> If the array allocation was really a concern, then the randomFill function
> should be a method on Array.prototyoe:
> Array.prototype.randomFill= function () {...}; /* return the this value */
>
> it might be used like:
> var rand = new Array(8).randomFill(); //create an array of 8 random
> 16-bit numbers
>
> The length parameter is unnecessary because the length is implicit in the
> array (and if this is about perf. you probably don't want to be dynamically
> changing the length of already allocated arrays).
> The same discussion of element size alternatives also applies.
>
> Of course we could do both. But really, if we want this to show up very soon
> in browsers keeping it to a single function or methods with minimal options
> is likely to yield the best results.
>
> Finally, as a dark horse we could consider using Strings rather than Arrays
> as JavaScript strings are sequences of 16-bit values and the individual
> element values are directly accessible.
> String.randomFill(length) //returns a string value containing length random
> 16-bit character values.
>
> Individual values would be accessed as:
> var rs=String.randomFill(2);
> var random32=(rs.charCodeAt(0)<<16)|rs.charCodeAt(1);
>
> But really, Arrays seem like they should work just fine.
>
> Allen
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
