operator overloading proposal

Brian Barnes ggadwa at charter.net
Tue May 10 15:15:58 UTC 2016


A note on this from somebody who's entire existence seems dedicated to 
stopping as much stuff as possible from getting GC'd, the example below:

 >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 };

Could += be a special case?  i.e.,

u+=v;

would call:

Class Point { ... other stuff ...
[whatever the syntax is](pt)
{
this.x+=pt.x;
this.y+=pt.y;
}
}

instead of desugaring to:

u=u+v;		// which would cause the creation of an object and
		// leave the other to be collected

For all I know, += might be doing such anyway in some engines, but for 
my stuff which is a lot of 3D math that could be a performance killer. 
It would be nice to be able to just add points and such, as long as the 
overhead is negligible.

[>] Brian

On 5/10/2016 10:52 AM, Isiah Meadows wrote:
> I would prefer syntax + internal slots, since you'll know at creation
> time whether the object has overloaded operators. It's much simpler for
> the engine to figure out, and it's more performant because you only need
> to check one thing instead of worrying about inheritance, own
> properties, etc.
>
> Also, it would be IMHO easier to read than a symbol (the computed
> property syntax is ugly IMO). Using a different concept than symbols
> would also fit better with value types whenever any of those proposals
> make it into the language (either the struct or special syntax).
>
>
> On Tue, May 10, 2016, 04:03 G. Kay Lee
> <balancetraveller+es-discuss at gmail.com
> <mailto:balancetraveller%2Bes-discuss at gmail.com>> wrote:
>
>     Yes, I think exposing operators through well-known symbols is an
>     interesting idea worthy of more exploration because it's precisely
>     the purpose of well-known symbols to expose and allow manipulation
>     to previously inaccessible internal language behaviors.
>
>     On Tue, May 10, 2016 at 1:59 PM, Kevin Barabash
>     <kevinb at khanacademy.org <mailto:kevinb at khanacademy.org>> wrote:
>
>         > 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
>         <mailto: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 <mailto: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
>                 <mailto: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
>                     <mailto: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
>                         <mailto: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
>                         <mailto:es-discuss at mozilla.org>
>                         https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>                     _______________________________________________
>                     es-discuss mailing list
>                     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>                     https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>                 _______________________________________________
>                 es-discuss mailing list
>                 es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>                 https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>             _______________________________________________
>             es-discuss mailing list
>             es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>             https://mail.mozilla.org/listinfo/es-discuss
>
>
>
>         _______________________________________________
>         es-discuss mailing list
>         es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>         https://mail.mozilla.org/listinfo/es-discuss
>
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto: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
>


More information about the es-discuss mailing list