David Herman wrote:
On Nov 2, 2012, at 12:05 PM, Yehuda Katz<[email protected]> wrote:
Seems like a small surface-area with a large impact on compilers.
At first glance, looks good to me.
Curiosity: Does this overlap with Brendan's work on value objects (i.e. will it
become moot in the face of them)
It could become unnecessary if you're working with value objects. If you had
ordinary numbers, you'd have to coerce them to u32 and then multiply:
var a = 0x7fffffff, b = 0x7fefefef; // both doubles
var result = int32(a) * int32(b); // int32
But value objects are still uncertain
I'm focusing on int64 and uint64 but making the framework as general
under the hood as possible (e.g., the operators stuff, a multimethod
variation that's inline-cacheable, based on an idea from Christian
Plesner Hansen).
The need for 64-bit ints is pretty strong in Node.js and I think this
means value objects are a priority for ES7.
and at the very least much farther off into the future -- post-ES6. Engines
could implement and ship Math.imul in very short order.
Agreed, and this kind of micro-evolution is important to support even
while working on value objects for post-ES6. It may be we end up with
int32 and uint32, but we don't need to if there's no strong use-case not
satisfied by Math.imul.
Note that there's no micro-evolutionary step involving Math.imul64 that
satisfies the int64/uint64 use-cases Node faces (buffer and file
sizes/offsets). You need 64-bit addition, subtraction, and probably
other operators -- and you need the data type, not just operations that
could be Math methods.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
