operator overloading proposal

Kevin Barabash kevinb at khanacademy.org
Thu May 12 05:16:59 UTC 2016


@Isiah: Great points.  One potential edge case though:

```js
class A {
    operator+ (other) { }
}

class B {
    operator+ (other) { }
}

const a = new A();
const b = new B();
const c = a + b;
```

In the case where both the left and right side have `[[OpPlus]]` do we
prefer the left side?

> But, do we really need operator overloading? A method can be used
instead, I think.

@Dawid: Suppose I create a class to represent complex numbers that looks
like this:

```js
class Complex {
    constructor(re, im) {
         Object.assign({ }, { re, im });
    }
    add(other) {
        return new Complex(this.re + other.re, this.im + other.im);
    }
    ...
}
```

I might want to create instance of `Complex` with plain old numbers or I
might want to use `BigNumber` instances.
Without operator overloading this means that I would have add methods to
`Number.prototype` or wrap each number
in an object with methods.  Neither of which are particular appealing.



On Wed, May 11, 2016 at 1:28 AM, Isiah Meadows <isiahmeadows at gmail.com>
wrote:

> 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.szlachta at 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 <isiahmeadows at 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 <ljharb at 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 <isiahmeadows at 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 <kevinb at 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 <
>>>>>> isiahmeadows at 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 <kdex at 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 <ggadwa at 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-discuss at gmail.com
>>>>>>>> > > > <mailto:balancetraveller%2Bes-discuss at 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
>>>>>>>> > > >     <kevinb at khanacademy.org <mailto:kevinb at 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-discuss at gmail.com
>>>>>>>> > > >         <mailto:balancetraveller+es-discuss at 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
>>>>>>>> > > >             <kevinb at khanacademy.org <mailto:
>>>>>>>> kevinb at 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-discuss at gmail.com
>>>>>>>> > > >                 <mailto:balancetraveller+es-discuss at 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
>>>>>>>> > > >                     <kevinb at khanacademy.org
>>>>>>>> > > >                     <mailto:kevinb at 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
>>>>>>>> > > >                         <kevinb at khanacademy.org
>>>>>>>> > > >                         <mailto:kevinb at 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 at mozilla.org
>>>>>>>> > > >                         <mailto:es-discuss at mozilla.org>
>>>>>>>> > > >
>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>>  _______________________________________________
>>>>>>>> > > >                     es-discuss mailing list
>>>>>>>> > > >                     es-discuss at mozilla.org <mailto:
>>>>>>>> > > es-discuss at mozilla.org>
>>>>>>>> > > >
>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>>  _______________________________________________
>>>>>>>> > > >                 es-discuss mailing list
>>>>>>>> > > >                 es-discuss at mozilla.org <mailto:
>>>>>>>> es-discuss at mozilla.org>
>>>>>>>> > > >                 https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >             _______________________________________________
>>>>>>>> > > >             es-discuss mailing list
>>>>>>>> > > >             es-discuss at mozilla.org <mailto:
>>>>>>>> es-discuss at mozilla.org>
>>>>>>>> > > >             https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >         _______________________________________________
>>>>>>>> > > >         es-discuss mailing list
>>>>>>>> > > >         es-discuss at mozilla.org <mailto:es-discuss at mozilla.org
>>>>>>>> >
>>>>>>>> > > >         https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >     _______________________________________________
>>>>>>>> > > >     es-discuss mailing list
>>>>>>>> > > >     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>>>>>>>> > > >     https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > >
>>>>>>>> > > > _______________________________________________
>>>>>>>> > > > es-discuss mailing list
>>>>>>>> > > > es-discuss at mozilla.org
>>>>>>>> > > > https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>> > > >
>>>>>>>> > > _______________________________________________
>>>>>>>> > > es-discuss mailing list
>>>>>>>> > > es-discuss at mozilla.org
>>>>>>>> > > https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>> > >
>>>>>>>> >
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> es-discuss mailing list
>>>>>>> es-discuss at mozilla.org
>>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> es-discuss mailing list
>>>>>> es-discuss at mozilla.org
>>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>>
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160511/7d3f4c3b/attachment-0001.html>


More information about the es-discuss mailing list