I just read this interesting article: http://www.2ality.com/2011/12/fake-operator-overloading.html?m=1
Wow. What iteresting "fake" overloading. Check out the `new Point(1, 2) + new Point(3, 4) + new Point(5, 6)` example. On Mon, Dec 28, 2015 at 11:36 AM, Sander Deryckere <[email protected]> wrote: > There are so many places where overloading would be useful., even between > different data types: > > * adding vectors > * multiplying vectors with matrices > * multiplying vectors with numbers > * multiplying or adding matrices > * adding (or subtracting) date objects (to get a time difference) > > Certainly in the case of working with vectors, you often need long > calculations with intermediate results. In those cases, it's also often > convenient to use short names (as the names are very local). So while > myFirstMatrix.multiply(mySecondMatrix) is acceptable, m1.multiply(m2) isn't > so acceptable. it distracts your attention too much to the name "multiply" > instead of letting you see the math behind it. > > I like JavaScript as a versatile language. It really gives the programmer > the responsibility to write good code. Of course you can write bad code with > operation overloading, but you can also write bad code now. > > Regards, > Sander > > > 2015-12-28 19:45 GMT+01:00 /#!/JoePea <[email protected]>: >> >> I'm kind of on the fence about it. `let result = >> matrix1.multiply(matrix2)` works for graphics, but `var result = >> matrix1 * matrix2` could be nice. >> >> Now that I think about it, I think I'll fall over onto the +1 side of >> the fence, because one of the things I love about JavaScript is how >> flexible it is as a language, and this adds to that flexibility that >> developers have in choosing how they write code. >> >> On Mon, Dec 28, 2015 at 10:26 AM, Coroutines <[email protected]> wrote: >> > On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck <[email protected]> >> > wrote: >> >> Who would think not knowing what `a+b` could do as a pitfall? /s >> >> >> >> I am not a big fan of overloading though, since it presents more mental >> >> complexity as they map to functions without looking like function >> >> calls. >> > >> > From the Wikipedia page on ecmascript it seemed like operator >> > overloading was already a for-sure planned feature of ES7, just not >> > fleshed out in a spec. I personally do love operator overloading - I >> > am used to it from Lua and Python and I think it can be quite nice. >> > Especially for making PEG combinator stuff: >> > >> > term = Any(1) // any 1 character >> > whitespace = Range(CharSet(' \t'), 1, Infinity) // space or tab, >> > repeated 1 or more times >> > indented_term = whitespace + term // will match: ' x' >> > >> > result = indented_term.parse(' text...') >> > >> > Okay this is a bad example. But when you're building a grammar >> > description from objects it can be quite fun to make use of operator >> > overloading for a much cleaner description - somewhat like a >> > domain-specific language (DSL) within JS. LPeg in Lua and PyPeg in >> > Python make this rather pleasant. >> > >> > Anyway, I suspect it won't matter what syntactic features Javascript >> > gains once WebAssembly gets adopted. We already have the fundamentals >> > like inheritance in place so that any language can compile to a >> > WebAssembly AST and run as one would expect. >> > _______________________________________________ >> > es-discuss mailing list >> > [email protected] >> > https://mail.mozilla.org/listinfo/es-discuss >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss > > _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
