Operator overloading for non-value objects

Domenic Denicola domenic at domenicdenicola.com
Tue Jan 14 12:20:39 PST 2014

JavaScript is in a sticky place, it seems. `===` should mean strict equality (modulo `-0`/`+0` and `NaN`, unfortunately), so just like `0 !== "0"`, we want `0 !== 0m`. That is, `===` won't be right for comparing numeric types, once we have multiple numeric types.

However, `==` already means way-too-sloppy equality: `0 == "0"`. Thus, even if we get operator overloading to give us `0 == 0m`, its usefulness is reduced, since we can't trust `==` unless we know both types are "compatible" (e.g. both numeric, or both immutable URL instances). An operator that is sometimes annoyingly sloppy, and sometimes usefully lenient, is going to be hard to use ("power users only").

What we're missing is the equality operator most languages have: neither too strict, nor too sloppy. One that gives `(0 op 0m) === true`, but `(0 op "0") === false`.

This could be achieved, I suppose, by allowing overriding of `===`. But is it OK for `0 === 0m`? Probably not, right? Especially since `0m` is a value "object", and we try to let `===` applied to objects mean reference equality.

So we're kind of screwed. We could always [927 it][1], and invent a new operator with the most useful semantics. (The return of `is`? `====`? `=dwim=`?) Alongside `==`, `===`, SameValue, and SameValueZero, that'd make 5 notions of equality in ES. Seems bad. I come back to my "kind of screwed" thesis.

[1]: http://xkcd.com/927/

From: Brendan Eich <brendan at mozilla.com>
Sent: Tuesday, January 14, 2014 14:55
To: Kevin Smith
Cc: Domenic Denicola; es-discuss
Subject: Re: Operator overloading for non-value objects

Kevin Smith wrote:
>     Your point about it being too late to salvage == (vs. ===) is
>     good, but perhaps with value objects plus further work to disable
>     implicit conversions, == will make a come-back -- but that's far
>     down the road.
> Work to disable implicit conversions?  Can you clarify?

It's a gleam in my eye, at least. Some day we may enable users to choose
to get exception, not toString, on myUrl == "haha". Details TBD, and not
via valueOf/toString hacking (which doesn't quite work).

> I'm actually quite wary (so far) of allowing the user to override an
> operator whose abstract meaning is already so abstruse.

You've seen the rationale, here it is again:

== is overloadable along with < and <= to cope with unordered values and
to enable common safe comparisons, e.g. 0m == 0.

!= and ! cannot be overloaded, to preserve De Morgan's Laws and other
obvious invariants.

There is no "abstruseness" in x == y when typeof-types match. Even when
they don't, for numeric types, the relationals and == are loose. We
won't change that. Adding value objects should afford new numeric types
the same expressiveness that number has, or usability impairments will
hamper adoption.

If it's ok to test !0 or even 0 == "0" (yes, I know == is not transitive
in full), then 0m == 0 or 0n == 0 should be supported too.


More information about the es-discuss mailing list