2008/9/4 Brendan Eich <[EMAIL PROTECTED]>: > On Sep 4, 2008, at 8:30 AM, Sam Ruby wrote: > > In particular, does that imply the need for a wrapper class? > > Yeah, if you want !0m == true then we are back to the future:
There's a reason why my weblog is called Intertwingly :-) > * There's a decimal primitive type, autowrapped when used as an object by > Decimal. > * The decimal primitive acts like a value type. > * Decimal wrapper instances are mutable objects manipulated by reference. > * Decimal.prototype contains methods, etc. > * Calling Decimal(x) as a function converts a la Number. > > This was an outcome Lars Hansen explored earlier this year or late last > year, when we were trying to align ES4 decimal (primitive only, shares > Number.prototype) with ES3.1 Decimal. > > Sorry I steered you down the "Decimal is an object" route. As you argued, > that plan is tenable if we can live with !0m == false, but it seems unusably > confusing and fatally frustrating to generic programming (if (!falsy) ...). Much good came out of the exercise. Decimal primitives won't share Number.prototype. I believe that any new types that this committee may contemplate in the future will bump up against this same constraint: namely if that type has any values which should be considered false, then they too will need to provide both a primitive and a wrapper. The end result is internally consistent, and simple. Number and Decimal are different types, but conversions (that are both precise and safely round trip) are applied when the two are mixed. The amount of changes to the following are minimal: http://intertwingly.net/stories/2008/08/29/estest.html I will, however, be adding a few more tests. Specifically, I want to ensure that Decimal mimics the existing behavior for Number with respect to the following: js> Number(1) === Number(1) true js> Number(1) === new Number(1) false > /be - Sam Ruby _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
