Operators overriding

Alexander Jones alex at weej.com
Mon Dec 28 18:19:57 UTC 2015


Regarding not knowing what `a + b` does: you *already* don't know because
it invokes `.valueOf`. If you already know the operands are typeof
"number", you're good to optimise just as much as with operator overloading.

Aside from that, we're back into arguments about the clarity benefits of

 * paren-free function invocation
 * non-member, postfix function call syntax, aka `::`

And finally, any discussion about the perceived "mental tax" of operators
would be incomplete without a reference to the definition of the `+`
operator in ECMAScript 2016[1]. Ever tried explaining to beginners what the
result of `[] + {}` is, while keeping a straight face?

1.
http://www.ecma-international.org/ecma-262/6.0/#sec-addition-operator-plus

On 28 December 2015 at 17:59, /#!/JoePea <joe at trusktr.io> wrote:

> I'm in favor of no overloading for the reason of the mental tax.
> People could write a program where everything is a mathematical
> operation (in looks, not necessarily functionality), which could
> encourage harder-to-read code. I think `this.plus(that)` is fine for
> objects. With a proper auto-completing editor, this really isn't that
> difficult. Plus, there's Sweet.js if you really want it.
>
> 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.
> >
> > On Mon, Dec 28, 2015 at 11:52 AM, Alexander Jones <alex at weej.com> wrote:
> >>
> >> Who would have thought using completely un-semantic idioms such as |0
> and
> >> !! would lead to issues down the line? /s
> >>
> >> On 28 December 2015 at 14:50, Nicolas B. Pierron
> >> <nicolas.b.pierron at mozilla.com> wrote:
> >>>
> >>> This is right, currently code such as "asm js" rely on "a | 0" and
> >>> "+a" to force a type interpretation. Having an override means that we
> >>> would have to guard explicitly against overridden the operator before
> >>> entering these sections of code.
> >>> This will increase the cost of cold calls.  If this is a frequent
> >>> path, then we would have to infer the type as long as possible to
> >>> remove such guards.
> >>>
> >>> Currently, proxies have more important issues in SpiderMonkey, as they
> >>> allow to instrument the lookup of properties (which is still in C++)
> >>> in a side-effectful way.
> >>>
> >>> On Sun, Dec 27, 2015 at 9:42 PM, Frankie Bagnardi <
> f.bagnardi at gmail.com>
> >>> wrote:
> >>> > Generally letting proxies do more things is a good thing, but what
> >>> > would be
> >>> > the cost in optimizing JITs? It seems like e.g. making `a + b` or `a
> |
> >>> > 0`
> >>> > more flexible would also make them slower.  Is this incorrect?
> >>> >
> >>> > On Wed, Dec 23, 2015 at 3:23 AM, KOLANICH <kolan_n at mail.ru> wrote:
> >>> >>
> >>> >> I dislike this proposal.
> >>> >> 1 It is not very good to limit overrideable operators to value
> >>> >> classes.
> >>> >> 2 It is not very good to have a lot of custom operators, it will
> break
> >>> >> code readability and will allow more efficient obfuscration.
> >>> >> 3 I think that most of binary non-assigning operators must return a
> >>> >> new
> >>> >> object and thats' why they should be not object methods, but the
> >>> >> methods
> >>> >> taking 2 (or more if chained!) objects and return the result usually
> >>> >> of same
> >>> >> type.
> >>> >>
> >>> >> вторник, 22 декабря 2015г., 21:45 +03:00 от Sander Deryckere
> >>> >> <sanderd17 at gmail.com>:
> >>> >>
> >>> >>
> >>> >> IMO, operator overloading is important and different enough to
> warrant
> >>> >> a
> >>> >> separate syntax.
> >>> >>
> >>> >> But the difficulty isn't in defining the operator, but in the
> >>> >> ambiguous
> >>> >> cases. Like what to do when there are 2 different types, how to make
> >>> >> sure
> >>> >> certain relations will stay correct, ...
> >>> >>
> >>> >> There's a nice presentation from Brendan Eich here:
> >>> >> http://www.slideshare.net/BrendanEich/value-objects2
> >>> >>
> >>> >> Regards,
> >>> >> Sander
> >>> >>
> >>> >> 2015-12-18 21:24 GMT+01:00 KOLANICH <kolan_n at mail.ru>:
> >>> >>
> >>> >> Hello. What do you think about overriding operators using proxies?
> >>> >>
> >>> >> For example
> >>> >> function A(r=""){
> >>> >> this.rep=r;
> >>> >> return new Proxy(this,{operators:{"+":function(a,b){return new
> >>> >> A(a.rep+"+"+b.rep);}}});
> >>> >> }
> >>> >> let a=new A("a"), b=new A("b");
> >>> >> let c=a+b;
> >>> >> console.log(c.rep);//a+b
> >>> >>
> >>> >>
> >>> >> _______________________________________________
> >>> >> 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
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Nicolas B. Pierron
> >>> _______________________________________________
> >>> 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/20151228/a886fc24/attachment.html>


More information about the es-discuss mailing list