Kevin Barabash (2016-05-11T05:27:37.000Z)
kevinb at khanacademy.org (2016-05-11T05:30:30.448Z)
> 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:
kevinb at khanacademy.org (2016-05-11T05:29:21.336Z)
> 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:
kevinb at khanacademy.org (2016-05-11T05:29:09.897Z)
> 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:
kevinb at khanacademy.org (2016-05-11T05:28:59.821Z)
> 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: