Operator overloading revisited

[Brendan Eich]

On Jul 3, 2009, at 5:29 AM, Christian Plesner Hansen wrote:

> This is the critical point.  Do you want operator overloading to
> extend to classic objects (that is, instances of user-defined
> functions) or to be restricted to the values/classes/types subset?
> That's not as much a technical discussion but a question of design
> philosophy.  I assumed that integration with the existing language was
> desirable.  If not then the proposal is moot.

Operators are currently hardcoded in the language, but the  
specification could be recast using multimethods or double dispach and  
then extended to allow users to define operators on new "types" -- but  
what would be the nature of those types?

Anything like a number (primitive, as you note the wrapping with  
Number is an old hack) does not act like a reference (object, typeof x  
== "object") type. It's a value type.

This quest for extensible value types was how TC39 generalized the  
problem statement raised by decimal.


> What does "usable" mean?  If operators did work for classic objects
> why not use them for scalars?

"Usable" takes in operators for new value types, along with literal  
notation. These are aspirations, not obviously out of reach.  
Waldemar's original JS2/ES4 work from ~10 years ago had "units": http://www.mozilla.org/js/language/js20-2002-04/core/lexer.html#units

Since number, boolean, and string are not classic objects the  
generalization from hardcoding does not proceed from "classic objects"  
to novel scalar types, rather from the non-null/void primitive types.

> There's === but I don't know why you
> would want it to be anything other than object identity.  Is anybody
> relying on (typeof a == typeof b && a == b) <=> a === b?

Lots of code on the web happens to depend on this because some folks  
(Doug Crockford recomments this) use === while others use == but  
"usually" with same-typed operands. I think I've even seen some code  
mix == and === usage.

/be