value objects

Beautiful!
- I would leave typeof as it is. But there should be a proposal for a strategy on how to clean up the whole instanceof/typeof mess. Possibilities: just a set of best practices, a new operator, etc.
- There should be literals for ints, but I would have at most two kinds – for whatever is considered most common, e.g.:
let a = -123i; // int
let b = -123l; // long
Rationale: There are only a few ways in which integers are normally used, those should be convenient, especially for newbies. In contract, for scientific computing, bignum(500) should not be a problem.
On Mar 20, 2012, at 5:04 , 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!
>> Dave
>> _______________________________________________
> es-discuss mailing list
>es-discuss at mozilla.org>https://mail.mozilla.org/listinfo/es-discuss>
--
Dr. Axel Rauschmayer
axel at rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120320/8a8d9bd9/attachment-0001.html>