Here's my thought, if we go with syntax.
```js
class Point {
// constructor, etc.
operator +(other) {
assert(other instanceof Point)
return new Point(
this.x + other.x,
this.y + other.y)
}
operator +=(other) {
assert(other instanceof Point)
this.x += other.x
this.y += other.y
}
}
```
On Tue, May 10, 2016, 11:16 Brian Barnes <[email protected]> wrote:
> 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
> > <[email protected]
> > <mailto:balancetraveller%[email protected]>> 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
> > <[email protected] <mailto:[email protected]>> 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
> > <[email protected]
> > <mailto:[email protected]>> 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
> > <[email protected] <mailto:[email protected]>>
> 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
> > <[email protected]
> > <mailto:[email protected]>> 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
> > <[email protected]
> > <mailto:[email protected]>> 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
> > <[email protected]
> > <mailto:[email protected]>> 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
> > [email protected]
> > <mailto:[email protected]>
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [email protected] <mailto:
> [email protected]>
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [email protected] <mailto:[email protected]>
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [email protected] <mailto:[email protected]>
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [email protected] <mailto:[email protected]>
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [email protected] <mailto:[email protected]>
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > [email protected]
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
