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 <[email protected]> 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 <[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.
> >
> > On Mon, Dec 28, 2015 at 11:52 AM, Alexander Jones <[email protected]> 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
> >> <[email protected]> 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 <
> [email protected]>
> >>> 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 <[email protected]> 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
> >>> >> <[email protected]>:
> >>> >>
> >>> >>
> >>> >> 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 <[email protected]>:
> >>> >>
> >>> >> 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
> >>> >> [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
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> Nicolas B. Pierron
> >>> _______________________________________________
> >>> 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
> >
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
