Operator overloading revisited

Mark S. Miller erights at google.com
Tue Jun 30 16:16:35 PDT 2009


On Tue, Jun 30, 2009 at 1:37 PM, Christian Plesner Hansen <
christian.plesner.hansen at gmail.com> wrote:

> Sorry about falling behind in a discussion I started.  I'll try to catch
> up.
>
> > Are you referring to
> > <https://mail.mozilla.org/pipermail/es-discuss/2009-January/008535.html>?
> It
> > starts with:
> >
> >>> Define a new nominal type named, let's say, "Operable". (I'm not stuck
> on
> >>> this name. Perhaps "Numeric"?) We don't yet know what nominal type
> system
> >>> Harmony will have, so for concreteness, and to separate issues, let's
> use
> >>> "instanceof" as our nominal type test, where only functions whose
> >
> > [...suggested restrictions on when this test applies, but all without
> > presuming any "type"s beyond what ES5 already supports...]
>
> Yes that's the one.  The main problem I had was with the use of
> "instanceof".  However, as I read the proposal again I've become
> unsure if I've read something into it that it doesn't say.  The way I
> understood it you would implement the + operator for Point instances
> something like:
>
> Point.prototype['+'] = function (that) {
>  if (that instanceof Point) {
>    return new Point(this.x + that.x, this.y + that.y);
>  } else {
>    return that['reverse+'](this);
>  }
> };
>
> // Ditto 'reverse+'
>
> Is that correct?
>

Almost. It's actually a bit worse than that, since presumaby, Points want to
be addable with Numbers:

Point.prototype['+'] = function (that) {
  if (that instanceof Point) {
   return new Point(this.x + that.x, this.y + that.y);
 } else if (that instanceof Number) {
   // again ignoring the difference between numbers and Numbers
   return new Point(this.x + that, this.y + that);
 } else {
   return that['reverse+'](this);
 }
};


>
> > ===. Neither do we want
> >
> >     Point(3, 5) === Point(3, 5)
> >
> > to be false.
>
> Don't we?  I can see that we want Point(3, 5) == Point(3, 5) to be true but
> ===?
>

Perhaps Complex(3, 5) === Complex(3, 5) is a better example?

In any case, I could live with these being false in order to avoid adding
value types to the language. On this one, I'm on the fence.


>
> > It seems to me that the Operable-test and value-type issues are
> orthogonal
> > to the core suggestion of your email: whether operator dispatch is based
> on
> > Smalltalk-like double dispatch, in which the left side is asymmetrically
> in
> > charge, or on mutual agreement which is indeed symmetric. The first
> bullet
> > could be changed to your proposal without affecting the rest of the
> > value-type issue.
>
> That's probably true, though I don't know how Operable solves the '+'
> problem so I couldn't say for sure.
>

Ignoring Operable, in your proposal, how would you handle the need to
preserve the legacy + behavior on legacy kinds of objects? The only other
possibility I foresee is duck typing on the presence of the 'this+' and/or
'+this' property names. That would work.

-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090630/9cde8ae5/attachment.html>


More information about the es-discuss mailing list