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 :-/).
/be
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
