Es-discuss - several decimal discussions

Maciej Stachowiak mjs at
Sun Aug 24 00:51:33 PDT 2008

On Aug 23, 2008, at 11:14 PM, Brendan Eich wrote:

> On Aug 23, 2008, at 5:45 PM, ihab.awad at wrote:
>> On Sat, Aug 23, 2008 at 11:30 AM, Sam Ruby <rubys at>
>> wrote:
>>> Having Decimal.parse(2) + 3 produce "23" is not what I would call
>>> "fail
>>> fast", as that is a term I would typically use for throwing an
>>> exception or
>>> the like.
>> Point well taken. Does Maciej's followup regarding valueOf throwing
>> solve the problem?
> It forces would-be Decimal users to call Decimal.add(Decimal.parse(s)
> + 3) (let's say s may or may not be 2 or "2"). Is that a solution for
> ES3.1? It's user-hostile instead of future-hostile.

Decimal.add is also effectively what other languages provide, and it  
doesn't seem critical to do better for ES3.1, as long as a better  
future solution is not blocked. The user-hostile approach seems  
adequate in Java for the specialists who particularly care. Throwing  
now would allow proper semantics for the operators to be defined later/

> Can we not do better, especially by not overconstraining the problem
> by subjecting its solution to the ES3.1 goals and schedule?

I suspect we can, which is why I'd rather not have decimal in ES3.1 at  
all, or if present as library-only.

>> Were ES designed, back in 1995, to be the language it has become, and
>> were there time back then to have thought about how the builtin
>> arithmetic and comparison generalizes to mixtures of decimals,
>> arbitrary precision integers, complex numbers, matrices and
>> polynomials, I would agree with you unequivocally. As matters stand,
>> I'm not so sure.
> I've been through as many what-if's and might-have-been's as anyone.
> JS clearly had too much implicit magic -- Perl-envy, if you will --
> to be as neatly extensible as we want, in hindsight.
> EIBTI, the Pythonistas say. But this need not mean explicit method
> calls instead of operators for any numeric extension, since that's
> pretty much unusable (except under SOX mandate :-/).
> We've often cited EIBTI in ES4 working group meetings. In general I
> daresay the TC39 committee is more in favor of avoiding implicit
> magic, especially conversions, now than ever (E4X, ECMA-357, is full
> of it, and it's a mess). But this doesn't mean that throwing when a
> Decimal is used in any not-guaranteed-to-be-numeric operand context
> is good.

Actually, throwing from valueOf would have the opposite effect. It  
would throw in numeric (or possibly-numeric) contexts but not in  
string contexts, where conversion to string would be performed (since  
toString would not throw). This would avoid any accidental mixing of  
decimal and binary floating point numbers. The main sadness would be  
due to the fact that string concatenation and numeric addition are the  
same operator.


More information about the Es-discuss mailing list