operator overloading proposal

Kevin Barabash kevinb at khanacademy.org
Tue May 10 05:59:26 UTC 2016


> And remember that decorators are essentially just a syntax to apply
functions to objects/classes at design time, so what you're proposing is
essentially some new global function, which is going against the current
trend and effort to better modularize/namespace all these utility
functions/methods.

That's a really good point.

> It has been mentioned and discussed in numerous places over the years,
you can find more info on this with some casual googling. For example:
https://news.ycombinator.com/item?id=2983420

Thanks for the link.  I played around with sweet.js a bit over the
weekend.  Using macros should work if we went with Python style operator
overloading.  Instead of defining methods like _ADD_, _SUB_ etc. we could
create some well-known symbols, maybe Symbol.plus, Symbol.times, etc.

```
class Point {
  constructor(x, y) {
    Object.assign(this, {x, y});
  }

  [Symbol.add](other) {
    return new Point(this.x + other.x, this.y + other.y);
  }
}

const u = new Point(5, 10);
const v = new Point(1, -2);

const w = u + v;  // desugars to u[Symbol.add](v)
console.log(w);   // { x: 6, y: 8 };
```

This would require default implementations to be defined on
Object.prototype for Symbol.plus, Symbol.times, etc.


On Sun, May 8, 2016 at 10:38 PM, G. Kay Lee <
balancetraveller+es-discuss at gmail.com> wrote:

> > Why not? The standard defines well-known symbols. Maybe `@operator`
> could be a well known decorator (assuming decorators get approved).
>
> Well... you make something into the standard with proposals, not why-nots,
> so in order to make that happen you need to draft another proposal for
> well-known decorators. And remember that decorators are essentially just a
> syntax to apply functions to objects/classes at design time, so what you're
> proposing is essentially some new global function, which is going against
> the current trend and effort to better modularize/namespace all these
> utility functions/methods. And maybe a new mechanism could be drafted for
> these new well-known decorators, so that we can hide these new functions
> somewhere... but by now I hope it's becoming clear that it's introducing
> way too much new surface area for the language in exchange for one small
> feature.
>
> > I haven't seen any proposals for macros, could you post a link?
>
> It has been mentioned and discussed in numerous places over the years, you
> can find more info on this with some casual googling. For example:
> https://news.ycombinator.com/item?id=2983420
>
>
>
> On Sun, May 8, 2016 at 2:51 PM, Kevin Barabash <kevinb at khanacademy.org>
> wrote:
>
>> I should update the demo code to show the `@operator` decorator in
>> addition to `Function.defineOperator`.
>>
>> Initially I started out with just the `@operator` decorator, but that
>> meant that each class would have to have knowledge of each of the classes
>> it might want to interact with before hand.  Having a separate
>> `defineOperator` function avoids this situation.
>>
>> It means that prototype style classes must be converted to the new class
>> syntax before operator overloading could be used.  Lastly, there may be
>> some cases where it makes sense to overload operators with existing 3rd
>> party code or built-in classes, e.g. adding set operations to Set using
>> operator overloading.
>>
>> > It's also apparent that the `@operator decorator` part of the proposal
>> is an effort trying to address this issue, but it really is not the
>> responsibility of the standard to try to define such a thing.
>>
>> Why not?  The standard defines well-known symbols.  Maybe `@operator`
>> could be a well known decorator (assuming decorators get approved).
>>
>> Slide 15 from http://www.slideshare.net/BrendanEich/js-resp shows syntax
>> for defining operators in value types which could be adapted as follows for
>> regular classes:
>>
>> ```
>> class Point {
>>    constructor(x, y) {
>>        this.x = +x;
>>        this.y = +y;
>>    }
>>    Point + Number (a, b) {
>>        return new Point(a.x + b, a.y + b);
>>    }
>>    Number + Point (a, b) {
>>        return new Point(a + b.x, a + b.y);
>>    }
>>    Point + Point (a, b) {
>>        return new Point(a.x + b.x, a.y + b.y);
>>    }
>> }
>> ```
>>
>> Having to define `+` twice for `Point + Number` and `Number + Point`
>> seems like busy work, but maybe it's better to be explicit.  What are you
>> thoughts about this syntax?
>>
>> > Another thing is that, IMHO, currently there are too much
>> quirks/conventions in the proposal that feel non-evident and non-flexible
>> which is destined to trip people over from time to time. It would be great
>> to make a proposal that's simple and don't include too much assumptions.
>>
>> Could you elaborator what quirks/conventions might trip people up?
>>
>> > Finally, I'm not sure about the current status of macros, but last I
>> heard of it, they say it's going to make its way into the standard pretty
>> soon (TM), and macros can do much of the things overloading could, and much
>> more.
>>
>> I haven't seen any proposals for macros, could you post a link?
>>
>>
>>
>>
>>
>>
>>
>> On Sat, May 7, 2016 at 9:55 PM, G. Kay Lee <
>> balancetraveller+es-discuss at gmail.com> wrote:
>>
>>> I'd say it's way too early to ask for a champion on this because just a
>>> quick skimming revealed a lot of places that didn't add up. For example,
>>> the proposal suggested that overloading is primarily targeted at making it
>>> easier to work with user-defined classes, but curiously a
>>> `Function.defineOperator()` method is proposed instead of some syntax that
>>> feels more tightly integrated with the class definition syntax.
>>>
>>> ```
>>>
>>> class Point {
>>>     constructor(x, y) {
>>>         Object.assign(this, { x, y });
>>>     }
>>>
>>>     toString() {
>>>         return `(${this.x}, ${this.y})`;
>>>     }
>>> }
>>> Function.defineOperator('+', [Point, Point], (a, b) => new Point(a.x + b.x, a.y + b.y));
>>>
>>> ```
>>>
>>> The demo code made this flaw evident - it looks like a giant step
>>> backward to define an instance method like this, don't you agree?
>>>
>>> It's also apparent that the `@operator decorator` part of the proposal
>>> is an effort trying to address this issue, but it really is not the
>>> responsibility of the standard to try to define such a thing.
>>>
>>> What I'd suggest is that perhaps you should rethink your proposed syntax
>>> and redesign it to become an extension of the ES6 class definition syntax.
>>>
>>> Another thing is that, IMHO, currently there are too much
>>> quirks/conventions in the proposal that feel non-evident and non-flexible
>>> which is destined to trip people over from time to time. It would be great
>>> to make a proposal that's simple and don't include too much assumptions.
>>>
>>> Finally, I'm not sure about the current status of macros, but last I
>>> heard of it, they say it's going to make its way into the standard pretty
>>> soon (TM), and macros can do much of the things overloading could, and much
>>> more.
>>>
>>> On Sun, May 8, 2016 at 8:51 AM, Kevin Barabash <kevinb at khanacademy.org>
>>> wrote:
>>>
>>>> I forgot to mention in my last email that I'm looking for a champion
>>>> for this proposal.
>>>>
>>>> On Sat, May 7, 2016 at 5:24 PM, Kevin Barabash <kevinb at khanacademy.org>
>>>> wrote:
>>>>
>>>>> Hi everyone,
>>>>>
>>>>> I've been working on implementing operator overloading and would like
>>>>> to submit a proposal.
>>>>>
>>>>> I think operator overloading would be a useful addition to the
>>>>> language.  In particular I think it would be useful for defining operations
>>>>> on common mathematical object types such as complex numbers, vectors,
>>>>> matrices, and sets.
>>>>>
>>>>> I've create a working prototype that consists of:
>>>>>
>>>>>    - babel plugin that rewrites operators as function calls
>>>>>    - a polyfill which defines these functions and which call the
>>>>>    correct argument-specific function based on the arguments' prototypes
>>>>>    - Function.defineOperator which can be used to define which
>>>>>    function an operator should use for the specified types
>>>>>    - "use overloading" directive which allows users to opt-in
>>>>>
>>>>> More details can be found at
>>>>> https://github.com/kevinbarabash/operator-overloading.
>>>>> The babel plugin can be found at
>>>>> https://github.com/kevinbarabash/babel-plugin-operator-overloading.
>>>>> I also have a demo project at
>>>>> https://github.com/kevinbarabash/operator-overloading-demo.
>>>>>
>>>>> The design was inspired by some of the slides from
>>>>> http://www.slideshare.net/BrendanEich/js-resp.
>>>>>
>>>>> – Kevin
>>>>>
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160509/8cea0466/attachment-0001.html>


More information about the es-discuss mailing list