Kevin Barabash (2016-05-08T06:51:04.000Z)
kevinb at khanacademy.org (2016-05-08T06:56:03.601Z)
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. Could you post a link any more info? Will it be something like sweet.js?