On Feb 22, 2011, at 5:31 AM, Erik Corry wrote:
> Having got up to speed on this discussion after a holiday here are my
> thoughts from a V8er:
>
> * I would prefer to see this in the DOM rather than in the language.
> Can't see why it needs to be in the language itself. Other languages
> generally don't have cryptographically secure random numbers in the
> language itself, they put them in the libraries. Other users of the
> DOM http://www.w3.org/DOM/Bindings might want to use the feature too.
> On the other hand this no big deal. If the committee feels that
> putting it in the language makes it somehow more righteous then put it
> there.
>
> * But let's not invoke node.js as a reason to put it in the language.
+1
> Generally their policy is not to put things in the core that could be
> libraries. Seems to me that putting 'var crypto = require("crypto");'
> works just fine for node and can give you a completely compatible
> interface.
>
> * Lets keep the interface simple. All considerations of GC or
> effciency look completely specious to me given the amount of data
> involved (measured in bits). Returning strings seems strange (crypto
> data is numbers. What about surrogate pairs - do we really want
> something in the standard that returns incorrect UTF-16?). I would be
> in favour of any interface that returns regular arrays of numbers or
> even simpler just a single number, either 0-1 like Math.random() or 8-
> or 32-bit values. But only one function please.
>
> * I realize that Math.random() is not an ideal interface to emulate.
> The reason I suggest it is that putting a new API into the core
> language that is completely unlike Math.random() feels very PHP like:
> http://www.tnx.nl/php.html Even though Math.random() and the new
> interface are not interchangeable it seems to me that there is value
> in consistency in terms of mental effort needed to to memorize the
> APIs.
>
> 2011/2/18 Oliver Hunt <oli...@apple.com>:
>> I don't think generating 16bit values is beneficial -- either 8bit values
>> for byte at a time processing or full [u]int32 makes more sense. I think
>> the only reason for 16bit to come up is ecmascript's notionally 16bit
>> characters.
>>
>> I would prefer polymorphism of some form, for example
>>
>> any gimmeRandom(numberOfRandomElements, constructor = [[]Builtin Array
>> constructor], min = 0, max = 1<<32 - 1) {
>> var result = new constructor(numberOfRandomElements);
>> for (var i = 0; i < numberOfRandomElements; i++)
>> result[i] = reallyRandomValue(min, max);
>> return result;
>> }
>>
>> This would solve all the use cases presented so far (except a string of
>> cryptographically secure values, which can be handled trivially so i've left
>> that as a task for the reader ;) ), and would avoid the shortcomings of the
>> existing array methods (only a finite set of types can be produced as
>> output).
>>
>> --Oliver
>>
>>
>> On Feb 16, 2011, at 5:37 PM, Brendan Eich wrote:
>>
>>> On Feb 16, 2011, at 5:33 PM, Allen Wirfs-Brock wrote:
>>>
>>>> On Feb 16, 2011, at 4:54 PM, David Herman wrote:
>>>>
>>>>> 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.
>>>>
>>>> Dave, most browsers other than FF4 internally box all integers with with
>>>> 32-significant bits.
>>>
>>> I'm not sure this is still true. Certainly on x64, but also on x86,
>>> NaN-boxing has taken over in many VMs.
>>>
>>>
>>>> Some may box with 31 or even 30 significant bits. So if we spec. the
>>>> value as a uint32 and (they are truly random enough) then at least half
>>>> and possible 75% or more of the values in the array will be boxed in many
>>>> browsers. Such boxing will have a much higher cost than immediate uint16
>>>> values. That's why I propose 16-bit values.
>>>
>>> Given the implementors on es-discuss, we should survey first. I'd hate to
>>> prematurely (de-)optimize.
>>>
>>> I agree with David Wagner that the API has to be dead-simple, and it seems
>>> to me having only 16-bit values returned in a JS array may tend to result
>>> in more bit-mixing bugs than if we used 32-bit elements, if programmers are
>>> carelessly porting code that was written for uint32 arrays.
>>>
>>> /be
>>> _______________________________________________
>>> 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
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
--
Alex Russell
slightly...@google.com
slightly...@chromium.org
a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
