value objects

Herby Vojčík herby at mailbox.sk
Tue Mar 20 01:27:38 PDT 2012


David Herman wrote:
> I had a great conversation today with my colleagues Michael Bebenita
> and Shu-Yu Guo, and we came up with what I think is a nicely
> conservative way to add new kinds of numbers to JS without breaking
> the  intuition that JS has only one type of primitive numbers.
>
> tl;dr: Pure, immutable objects that can be optimized to unboxed
> integers.
>
> Examples:
>
>      let x = uint64(17);
>      let y = uint64(17);
>      console.log(x === y)            // true
>      console.log(typeof x)           // "object"
>      console.log(Object.isValue(x))  // true
>      console.log(Object.isValue({})) // false
>
>      function factorial(n) {
>          return n<= 1 ? bignum(1) : n * factorial(n - 1);
>      }
>
>      console.log(factorial(bignum(500)));
>      // 122013682599111006870123878542304692625357434280319284219241
>      // 358838584537315388199760549644750220328186301361647714820358
>      // 416337872207817720048078520515932928547790757193933060377296
>      // 085908627042917454788242491272634430567017327076946106280231
>      // 045264421887878946575477714986349436778103764427403382736539
>      // 747138647787849543848959553753799042324106127132698432774571
>      // 554630997720278101456108118837370953101635632443298702956389
>      // 662891165897476957208792692887128178007026517450776841071962
>      // 439039432253642260523494585012991857150124870696156814162535
>      // 905669342381300885624924689156412677565448188650659384795177
>      // 536089400574523894033579847636394490531306232374906644504882
>      // 466507594673586207463792518420045936969298102226397195259719
>      // 094521782333175693458150855233282076282002340262690789834245
>      // 171200620771464097945611612762914595123722991334016955236385
>      // 094288559201872743379517301458635757082835578015873543276888
>      // 868012039988238470215146760544540766353598417443048012893831
>      // 389688163948746965881750450692636533817505547812864000000000
>      // 000000000000000000000000000000000000000000000000000000000000
>      // 0000000000000000000000000000000000000000000000000000000
>
> By defining new object types that are immutable, implementations are free to choose among many representations. They can copy the data or share references whenever they want. Since the integers encapsulate only their bits, optimizing implementations can use a 64-bit integer payload. And fully unboxed representations can literally be 64 bit integers (at least, in optimized code where types have been properly inferred). Finally, it's possible to partially evaluate constructors like
>
>      uint64(17)
>
> because the constructor is pure. So even if we didn't have custom literal syntax like 17u64 (which, incidentally, we could), we should still be able to get the same performance.
>
> This proposal involves one major change in semantics: the built-in operators have to be overloaded to handle the new types. Rather than go all the way towards user-defined value types, though, I've stuck for now with just a fixed set of built-in ones. It's forward-compatible with user-defined overloading, in case we ever wanted to go all the way.
>
> But the nice thing is, since they are all just objects, there's no shame in having a multiplicity of new types, including:
>
> * uint8, int8
> * uint16, int16
> * uint32, int32
> * uint64, int64<-- hey everyone, look at this, this is the important part, right here
> * bignums
> * IEEE754r decimal
> * complex numbers (if anyone cares?)
> * exact rationals (a bridge too far?)
>
> For all of these, the answer to `typeof` is still just "object". For the most part, they just feel like a nice "batteries included" library.
>
> There's a rough draft of the strawman here:
>
>      http://wiki.ecmascript.org/doku.php?id=strawman:value_objects
>
> Comments welcome!

Hm, I feel a bit conservative... I think having single number type has 
its pluses.

I'd only include bignum and added MAX_INT (and probably LIMIT_INT_POWER2 
and LIMIT_INT_POWER10) to Number. If there is a chance that IEEE754r 
will be good enough to adopt in next five years, I'd just update Number 
to be 128bit and so MAX_INT gets higher as well as LIMIT_INT_POWER2 
(that goes well beyond 64) and LIMIT_INT_POWER10, so they will have 
their int64 and uint64 there.

I understand lots of apps want "native" int64 as soon as possible, but I 
do not like "uint64" etc. "types" - they are too technical, there are 
lots of them, one then must check what conversions are safe ... whatever.

> Dave

Herby


More information about the es-discuss mailing list