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