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