Operator overloading revisited
Christian Plesner Hansen
christian.plesner.hansen at gmail.com
Fri Jul 3 05:29:38 PDT 2009
> There are lots of subsets in the language already, this is a teaching and
> user preference outcome that we can't and shouldn't stop. Multiple paradigms
> and well-ordered subsets are not a problem, they are a success condition.
> But adding operators without considering first-class value types (==/=== and
> literal syntax) looks like a mistake.
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.
> No, because for two numbers a and b, a == b <=> a === b. In fact for any two
> values, (typeof a == typeof b && a == b) <=> a === b. If we want to support
> usable numeric and similar "scalar" type extensions, we might want to preserve
> this logic.
(I forgot to respond to this from a previous message)
What does "usable" mean? If operators did work for classic objects
why not use them for scalars? 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?
More information about the es-discuss