If the intent is to get ECMAScript implementations to quickly provide this
function then I would suggest that it be specified only in terms of things that
are already in ES5. That would preclude use of anything from the Harmony
binary data strawman.
I don't particularly see why a "binary array" is needed in this situations. A
regular ES5 array is perfectly capable of holding the numeric results. 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?
I don't understand the use cases that would justify the various integer length
options for the random elements.. One reasonable size seems fine. I would
probably go with 16 bit units in recognitions that many JavaScript
implementations have optimized small integer sizes < 32 bits. If you want 8
bit or 32 bit values, assemble them yourself out of the 16 bits values.
Alternative, if you are are attached to pure binary data. The function could
return a string value, as ECMAScript strings are really immutable vectors of
16-bit unsigned values.
In either case, I would attach the method to Array (or string) if we went down
that path:
Array.randomValues = function randomValues (len) {
//built-in
//Return an Array of ToUInt32(len) elements where each element is a number
in the range 0 to 65535
// The values of the elements must be generated using a strong crypto PRNG
// If ToUInt32(len) random values are not available, throw a RangeError
Exception
alternatively,
String.randomValues = function randomValues (len) {
//built-in
//Return an string value consisting of ToInteger(len) characters.
// The character code of the element of the string must be generated using a
strong crypto PRNG
// If ToInteger(len) is not a positive integer or if that many random values
are not available, throw a RangeError Exception
On Feb 14, 2011, at 2:25 PM, Mark S. Miller wrote:
> While we're waiting for Adam to subscribe to es-discuss and repost his
> messages on this thread, this one seems worth pre-posting.
>
> Changes needed for this to become an EcmaScript strawman:
>
> Replace references to ArrayBufferView with appropriate abstractions from
> <http://wiki.ecmascript.org/doku.php?id=strawman:binary_data>.
> Replace WebIDL as a specification language with a JavaScript based API spec.
> Get rid of the dependence on "window". Probably avoid introducing a new
> global "crypto" as well, though we can argue about that.
>
> Are there any other lurking browser dependencies in Adam's spec that we need
> to scrub away?
>
>
> On Mon, Feb 14, 2011 at 2:08 PM, Adam Barth <[email protected]> wrote:
> On Mon, Feb 14, 2011 at 12:49 PM, Brendan Eich <[email protected]> wrote:
> > On Feb 14, 2011, at 12:26 PM, Adam Barth wrote:
> > > Ok. I'll write up a spec later today.
> >
> > Thanks.
>
> Done: http://wiki.whatwg.org/wiki/Crypto
>
> Feedback appreciated.
>
> Adam
>
>
>
> --
> Cheers,
> --MarkM
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
