Operators overriding

/#!/JoePea joe at trusktr.io
Mon Dec 28 17:59:20 UTC 2015


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
>


More information about the es-discuss mailing list