operator overloading proposal

G. Kay Lee balancetraveller+es-discuss at gmail.com
Mon May 9 05:38:47 UTC 2016


> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160509/e4343a06/attachment-0001.html>


More information about the es-discuss mailing list