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
