Operator overloading revisited
brendan at mozilla.com
Fri Jul 3 05:40:10 PDT 2009
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.
More information about the es-discuss