Operator overloading for non-value objects

Domenic Denicola domenic at domenicdenicola.com
Tue Jan 14 18:51:30 PST 2014


Heh, yes, damned if you do, etc. etc. I was trying to think up a practical example where this would cause problems (e.g. in CSS libraries strings and numbers often mix), but all my cases involved an `==`-using third party library, in which case you'd just pass it `Number(myLong)` instead of `myLong` directly and move on with your life.

-----Original Message-----
From: Brendan Eich [mailto:brendan at mozilla.com] 
Sent: Tuesday, January 14, 2014 21:48
To: Domenic Denicola
Cc: Kevin Smith; es-discuss
Subject: Re: Operator overloading for non-value objects

Domenic Denicola wrote:
> From: es-discuss [mailto:es-discuss-bounces at mozilla.org] On Behalf Of 
> Brendan Eich
>
>> >  js>  0L == "0"
>> >  typein:2:0 TypeError: no operator function found for ==
>
> Hmm, upon seeing this in action, I'm not sure how I feel about `==` throwing.

Oh for crying out loud!

half a :-)

You can't please anyone around here...

>   It doesn't normally do that (modulo bad custom `valueOf`/`toString` methods), so I think there will be a lot of code that assumes when it `==`s two values it doesn't need to wrap that expression in `try`/`catch`.
>
> `do { try { x == y } catch { false } }`, the new `x == y`?

So what? Exceptions for the insane (intransitive, lossy) == cases are
*better* than toString/valueOf.

JS is damned if it does, and damned if it doesn't.

Anyway, value objects are not dispatching to toString or valueOf when used with arithmetic operators. That's the design. Given == and <=, the rest follows.

/be


More information about the es-discuss mailing list