I'm not sure I'll be able to contribute much -- I've not kept up with JS since around the time of the original discussion in 2009 and the language has evolved a lot since then. But I have given the proposal some thought since so I'll put those reflections out there in case they're relevant to the discussion. The original idea sprang from a discussion about adding a decimal type to JS. I didn't think a decimal type belonged in the core of the language and the suggestion was meant as a lesser evil. A way to support decimal -- and longer term other types -- as libraries such that there would be less pressure to put new types in the core language. (It wasn't a hidden agenda either, in context; I talk about decimal in the original email[1]) Then decimal went away which reduced that pressure. Without decimal as a greater evil I'm not sure I would have thought operator overloading was a good idea even back then. Today I don't think the proposal is very good. For one thing it's in the flavor of 2009-era JS, and even back then it felt a little backward- looking. It also conflates two things which should probably be orthogonal: operator overloading and multiple dispatch. Operator overloading is conceptually a simple mechanism, lots of languages similar to JS has it. Multiple dispatch can be really powerful (in practice if not in theory) but also potentially incredibly complex. There are hard unsolved problems around it, particularly modularity. If I was to put together a proposal today I would put the operator overloading aspect aside first and focus on multiple dispatch. If there is a solution, great -- but then I'd suggest providing that as a full language feature in itself instead of conflating it with a convenient operator syntax. Multiple dispatch is useful and if it can be supported cleanly there is no reason to restrict it to methods with a particular syntax -- that just creates a perverse incentive to express things in terms of operators to get the multiple dispatch behavior when the incentive should be purely that the syntax is appropriate. Or maybe no acceptable multiple dispatch mechanism can be designed, or maybe adding one isn't desirable even if there is a design. Either way the design space for operator overloading has shrunk considerably, in bother cases ideally to a thin syntactic layer on top of normal methods. c On Sun, Jun 5, 2016, at 03:22 PM, Benjamin Gruenbaum wrote: > I see some discussion is happening - that's good. > > As I don't want to see the tremendous amount of work people put into > value types and operator overloading go to waste - let's bring Brendan > and Christian into this discussion and start with a link to Brendan's > 2013 slides: > > http://www.slideshare.net/BrendanEich/value-objects > > Let's consider value semantics for this. > > > 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 kevinbarabash/operator-overloading. The > > babel plugin can be found at kevinbarabash/babel-plugin-operator- > > overloading. I also have a demo project at > > kevinbarabash/operator-overloading- > > demo. > > The design was inspired by some of the slides from > www.slideshare.net/BrendanEich/js- > resp. > > _________________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss
Links: 1. https://esdiscuss.org/topic/operator-overloading-revisited
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
