> 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 <kev...@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-disc...@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 <kev...@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 <kev...@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@mozilla.org >>> https://mail.mozilla.org/listinfo/es-discuss >>> >>> >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
