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
