type coercion of `.valueOf` of `.toString` variety is guaranteed to return a specific type (based upon hints). There is a small surface area to what the total possible outcomes of using `+` and having coercion could return. Not true in a operator overloading world.
I am not saying that confusions are not present, just that we should not add more. Having one wart does not merit having more. On Mon, Dec 28, 2015 at 12:19 PM, Alexander Jones <[email protected]> wrote: > 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
