Operator overloading revisited

[Christian Plesner Hansen]

> Likewise, for user-defined function foo, foo.prototype is writable -- but
> not so for built-in constructor functions, and not so for classes as sugar
> (more below).

All JS code currently in existence is based on user-defined functions.
 For me that is the only case worth considering.  That might explain
the differences in our views.

I'm not a language revolutionary, I prefer gradual evolution.

> The original "classes as sugar" sketch Mark did to general agreement at Oslo
> included freezing the class object (constructor function) *and* bind the
> class name as a const (neither writable nor configurable in the binding
> object or frame).
>
> So a higher-integrity "fix" would be to make classes as proposed for Harmony
> (details still in flux, I think) the cornerstone for operator dispatch. I
> think this is the plan for "value types", based on discussion at the last
> TC39 meeting. Mark will let us know if he disagrees.

If you have the option to use a model that works with the existing
language and that integrates well even (that's subjective of course)
why would you limit it to classes or values?  The reliance of these
new features on each other will just lead them to become a
language-within-a-language, rather than an evolution of the existing
language.

> You could, but your proposal nicely avoided noisy ".prototype" expressions
> all over, as Allen suggested in reply.

That was a typo.

> Adding Complex, Decimal, Rational, Point, etc. for most users implies, nay
> cries out for being able to use these names without having to suffix them
> with ".prototype". If the binding of the constructor name in its object or
> frame *and* the binding of its 'prototype' property are locked down due to
> how classes as sugar work, then we should be able to rely on the constructor
> / prototype relationship.

If people can live with defining their methods as

Foo.prototype.bar = function () { ... }

I think they can live with writing .prototype when defining operators.
 In fact I like the uniformity that you have to use the prototype in
both cases.  Note that library users won't see this, only the library
implementer.  In any case, what users will "cry out for" is
speculation.

>> Whether or not A's '+' operator uses 'this', it's still a part of A's
>> behavior and the most consistent place to put it is where A's other
>> behavior is, its prototype.
>
> Could be, or one could use an optimized multimethod matrix, or some other
> implementation approach. Again I do not see why the spec should dictate
> observable prototype properties, internal or otherwise. If it just uses this
> model but keeps it concealed, then I'm ok with it provided we don't close
> the door on multimethods prematurely.

JS allows introspection and self-modification and both are widely used
and cited as advantages of the language.  I would want to extend that
to cover operators as well.  Having an internal property with some
associated utility methods on Object is a nice way to get that.


-- Christian