Es-discuss - several decimal discussions

Brendan Eich brendan at
Sun Aug 24 10:15:50 PDT 2008

On Aug 24, 2008, at 1:12 AM, Brendan Eich wrote:

> On Aug 24, 2008, at 12:51 AM, Maciej Stachowiak wrote:
>>> 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.
> Of course, and my "not-" was a thinko. I meant "guaranteed-to-be-
> numeric".

On reflection, I should have written "not-guaranteed-to-be-string"  
context. The preferredType hint to [[DefaultValue]] is either absent,  
number, or string. It seems to me we have to throw in the absent and  
number cases to be future proof.

Throwing in these cases bites not only +, but == and !=. Old and  
heretofore type-agnostic code that uses something like

   if (typeof v == "object" && v == memoized_object) {
     // handle the memoized_object special case

to guard for a particular object reference would start throwing if  
passed a decimal. One could say that such code ought to have used  
===, but tell it to the long-gone consultant who wrote it.

Mandatory explicit d.toString() calling instead of "..." + d, e.g.,  
is awkward, but people could learn if they had to, and curse our  
names. Better if they didn't have to work around future-proofing (or  
curse our names).

Maybe this isn't too big a problem in practice, but we don't know. If  
we can get operators up and running, we won't have to find out the  
hard way. So I'd still rather not go there (you agree, sorry for  
belaboring; I'm still preaching past your choir to the heathen who  
would put only the BigMistake-or-throw Decimal API into ES3.1 :-/).


More information about the Es-discuss mailing list