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
