es-discuss Digest, Vol 106, Issue 72

John Gardner gardnerjohng at gmail.com
Tue Dec 29 12:27:39 UTC 2015


I think introducing operator overloading has the potential to introduce
more problems than it solves.

JavaScript is a versatile language, yes, but part of that versatility rests
with simplicity. Overloading operators might make writing dynamic code
easier, but it also becomes a lot harder to discern an author's intent if
values are calculated unexpectedly. For example, when one typecasts
something to an integer, they'd expect it to follow the logical JavaScript
laws of how values are coerced to Numbers. Code becomes harder to predict,
and all for very little gain.

I really don't think it's worth the added complexity. Just because we can,
doesn't mean we should.

/* 2¢ */

On 29 December 2015 at 23:00, <es-discuss-request at mozilla.org> wrote:

> Send es-discuss mailing list submissions to
>         es-discuss at mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
>         es-discuss-request at mozilla.org
>
> You can reach the person managing the list at
>         es-discuss-owner at mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>    1. Re: Re[2]: Operators overriding (Sander Deryckere)
>    2. Re: Re[2]: Operators overriding (/#!/JoePea)
>
>
> ---------- Forwarded message ----------
> From: Sander Deryckere <sanderd17 at gmail.com>
> To: "/#!/JoePea" <joe at trusktr.io>
> Cc: es-discuss <es-discuss at mozilla.org>
> Date: Mon, 28 Dec 2015 20:36:38 +0100
> Subject: Re: Re[2]: Operators overriding
> 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
>>
>
>
>
> ---------- Forwarded message ----------
> From: "/#!/JoePea" <joe at trusktr.io>
> To: Sander Deryckere <sanderd17 at gmail.com>
> Cc: es-discuss <es-discuss at mozilla.org>
> Date: Mon, 28 Dec 2015 14:09:48 -0800
> Subject: Re: Re[2]: Operators overriding
> 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 <sanderd17 at gmail.com>
> 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 <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
> >
> >
>
>
> _______________________________________________
> 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/20151229/01c693cf/attachment.html>


More information about the es-discuss mailing list