That's the current state of things. I think the main issue at hand is ergonomics. Haskell, the MLs, and Swift solved it by allowing inline functions and operators as functions (that wouldn't work in a dynamic language). Scala solved it by magic methods for unary operations and the fact nearly every character is a valid identifier for binary ones (JS can't use that because of back compat issues). Lua, Ruby, Python, and Kotlin solved it by using magic methods. C++ solved it with the `operator` keyword.
On Wed, May 11, 2016, 03:26 Dawid Szlachta <dawidmj.szlac...@gmail.com> wrote: > But, do we really need operator overloading? A method can be used instead, > I think. > > 2016-05-11 8:53 GMT+02:00 Isiah Meadows <isiahmead...@gmail.com>: > >> Efficiency and optimization. If you're stupid enough to want to violate >> those priorities in a public API, it's your own fault. But if you want to >> optimize updating a collection (i.e. zero allocation update for a >> persistent map) or increment a vector by another without having to create >> an intermediate vector, you'll want to implement the assignment operator as >> well as the standard math operator. >> >> On Wed, May 11, 2016, 02:46 Jordan Harband <ljh...@gmail.com> wrote: >> >>> Why would you ever want to violate the algebraic properties of >>> operators, such that `a += b` wasn't exactly equivalent to `a = a + b`, `a >>> *= b` not equivalent to `a = a * b`, etc? I'm quite confident that any >>> proposal that allowed for that would get tons of pushback. >>> >>> On Tue, May 10, 2016 at 11:26 PM, Isiah Meadows <isiahmead...@gmail.com> >>> wrote: >>> >>>> 1. Yes, they would be inherited, but not on the prototype itself (it >>>> would technically be parasitic). It would be modeled with internal slots, >>>> so that the properties are themselves immutable and transparent, so the >>>> only way to inherit would be via the class syntax or `Reflect.construct`. >>>> Engines could model this similarly to prototypes internally, while still >>>> appearing to conform to spec, since there's no other way to access the >>>> function without explicit reference via a decorator. And if it's not >>>> decorated, you can transparently fast path the calls automatically and >>>> optimize the function at compile time for exactly the number of arguments >>>> (any different is a syntax error, like with getters and setters). >>>> >>>> 2. I'm intentionally trying to avoid any semantics that would rely on >>>> adding more values to the global scope. First, it's harder to optimize a >>>> `hasOwnProperty` check. Second, when you allow properties to be dynamically >>>> added, you make it impossible to lower `foo + bar` to a single instruction >>>> if they're both numbers, because someone can change the Number prototype to >>>> have one of the operators on it, and now, the assumption, previously >>>> prevalent, is now invalid. Third, we shouldn't need to add 15+ new symbols >>>> to accommodate a simple operation. >>>> >>>> 3. If it's pure syntax, you won't have the edge cases of `x += y` >>>> having to desugar to `x = x[Symbol.assignPlus](y)` and so on. You just look >>>> for an `[[OpAssignPlus]]` on `x`, and if it exists, call it as >>>> `x.[[OpAssignPlus]](y)`. >>>> Else, you check for `[[OpPlus]]`, and set `x` to `x.[[OpPlus]](y)`. If >>>> neither exists, you fall back to the old algorithm. This can be easily >>>> optimized by the fact engines only need to check this if the value is an >>>> object. Numbers and strings don't have this slot. >>>> >>>> Note: If the right side has an operator defined, but the left side >>>> doesn't, and if the operator checked for isn't an assignment one, the right >>>> side's operator is checked and called. Or basically, beyond assignment, the >>>> mere existence of a slot takes precedence over no slot, to make >>>> transitivity easier with primitives. To clarify, in the below case: >>>> >>>> ```js >>>> class C { >>>> constructor(x) { this.x = x } >>>> operator +(x) { >>>> if (x instanceof C) { >>>> return this + x.x * 2 >>>> } >>>> return this.x + x >>>> } >>>> } >>>> >>>> assert(new C(1) + 1 === 1 +1) >>>> assert(1 + new C(1) === 1 + 1) >>>> assert(new C(1) + new C(2) === 1 + 2*2) >>>> assert(new C(2) + new C(1) === 2 + 1*2) >>>> ``` >>>> >>>> On Wed, May 11, 2016, 01:27 Kevin Barabash <kev...@khanacademy.org> >>>> 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. >>>>> >>>>> Will operators defined on a class work with instances of a subclass? >>>>> >>>>> > Could += be a special case? i.e., >>>>> >>>>> For sure. We could define `Symbol.assignPlus`, `Symbol.assignTimes`, >>>>> etc. with `u += v;` desugaring to `u = u[Symbol.assignPlus](v)`. The >>>>> reason why we can't do something do `u[Symbol.assignPlus](v)` is that >>>>> there's no way to define a method on Number, String, etc. that would >>>>> reassign their value. >>>>> >>>>> > it appears to me that overloading an operator multiple times (e. g. >>>>> unary/binary plus operator) might become >>>>> > painful, assuming that the semantics follow the same variadic >>>>> approach that regular functions do. >>>>> >>>>> Another pain point is handling cases where you want one class to >>>>> interoperate with another. In one of the example above methods are >>>>> defined >>>>> that allow `Point`s and `Number`s to be added to each other. In order to >>>>> maintain the commutativity of `+` we need to define `operator+` / >>>>> `[Symbol.add]` methods on both `Point` and `Number`. One potential >>>>> solution to this problem is create `Symbol.plusRight`, `Symbol.timesRight` >>>>> for all of the commutative/symmetric operators. >>>>> >>>>> I feel like this ends up making things more complex because there are >>>>> more methods to implement and the methods have to be more complex b/c they >>>>> have to do type checking when overloaded. >>>>> >>>>> Maybe `operator+` could work like the `@operator` decorator by calling >>>>> `Function.defineOperator` behind the scenes. In this situation, instead >>>>> of >>>>> methods being added to classes, the `Function` object has well-defined >>>>> methods that look up the correct function to call based on the argument >>>>> types. `u + v` desugars to `Function[Symbol.plus](u, v)`. This is >>>>> definitely slower than internal slots, but if we're doing runtime type >>>>> checking in the method we may as well have it be automatic. My hope is to >>>>> eventually use static typing (flow b/c I'm using babel) to remove the >>>>> lookup cost. >>>>> >>>>> >>>>> On Tue, May 10, 2016 at 7:07 PM, Isiah Meadows <isiahmead...@gmail.com >>>>> > wrote: >>>>> >>>>>> You're correct in that the operator doesn't do any type checking (it >>>>>> dispatches from its first argument, but that's just traditional OO). >>>>>> >>>>>> On Tue, May 10, 2016, 20:28 kdex <k...@kdex.de> wrote: >>>>>> >>>>>>> @Isiah: Comparing your syntax proposal to `Function.defineOperator`, >>>>>>> it appears to me that >>>>>>> overloading an operator multiple times (e. g. unary/binary plus >>>>>>> operator) might become painful, >>>>>>> assuming that the semantics follow the same variadic approach that >>>>>>> regular functions do. >>>>>>> >>>>>>> That is, of course, unless you intend to handle all operator >>>>>>> overloads in a single `operator +(...args) {}` >>>>>>> definition. But then again, something like `Function.defineOperator` >>>>>>> seems cleaner and suggests implicit >>>>>>> (optional?) type checks with its second argument. >>>>>>> >>>>>>> On Dienstag, 10. Mai 2016 15:25:32 CEST Isiah Meadows wrote: >>>>>>> > 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 <gga...@charter.net> >>>>>>> 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 >>>>>>> > > > <balancetraveller+es-disc...@gmail.com >>>>>>> > > > <mailto:balancetraveller%2bes-disc...@gmail.com>> 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 >>>>>>> > > > <kev...@khanacademy.org <mailto:kev...@khanacademy.org>> >>>>>>> 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 >>>>>>> > > > <balancetraveller+es-disc...@gmail.com >>>>>>> > > > <mailto: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 <mailto: >>>>>>> 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 >>>>>>> > > > <mailto: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 >>>>>>> > > > <mailto: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 >>>>>>> > > > <mailto: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 >>>>>>> > > > <mailto:es-discuss@mozilla.org> >>>>>>> > > > >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> _______________________________________________ >>>>>>> > > > es-discuss mailing list >>>>>>> > > > es-discuss@mozilla.org <mailto: >>>>>>> > > es-discuss@mozilla.org> >>>>>>> > > > >>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > _______________________________________________ >>>>>>> > > > es-discuss mailing list >>>>>>> > > > es-discuss@mozilla.org <mailto: >>>>>>> es-discuss@mozilla.org> >>>>>>> > > > https://mail.mozilla.org/listinfo/es-discuss >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > _______________________________________________ >>>>>>> > > > es-discuss mailing list >>>>>>> > > > es-discuss@mozilla.org <mailto: >>>>>>> es-discuss@mozilla.org> >>>>>>> > > > https://mail.mozilla.org/listinfo/es-discuss >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > _______________________________________________ >>>>>>> > > > es-discuss mailing list >>>>>>> > > > es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> >>>>>>> > > > https://mail.mozilla.org/listinfo/es-discuss >>>>>>> > > > >>>>>>> > > > >>>>>>> > > > _______________________________________________ >>>>>>> > > > es-discuss mailing list >>>>>>> > > > es-discuss@mozilla.org <mailto: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 >>>>> >>>> >>>> _______________________________________________ >>>> 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