Operators overriding

Bradley Meck bradley.meck at gmail.com
Mon Dec 28 17:55:45 UTC 2015


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20151228/4bce1ac4/attachment-0001.html>


More information about the es-discuss mailing list