Operators overriding

Bradley Meck bradley.meck at gmail.com
Mon Dec 28 18:45:41 UTC 2015


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 <alex at weej.com> 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 <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/ad05b0d9/attachment.html>


More information about the es-discuss mailing list