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
