Operators overriding

Sander Deryckere sanderd17 at gmail.com
Mon Dec 28 19:36:38 UTC 2015


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 <joe at trusktr.io>:

> 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 <coroutines at gmail.com> wrote:
> > On Mon, Dec 28, 2015 at 9:55 AM, Bradley Meck <bradley.meck at gmail.com>
> 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
> > 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/20151228/813bc965/attachment.html>


More information about the es-discuss mailing list