Operator overloading for non-value objects

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Jan 14 13:19:49 PST 2014


if you are not sure and you expect == to act like === within objects /
types then just use === and leave == for checks behind the typoef as
Brendan said.

Once again, let power users have the control they'd like to, specifications
should not prevent people from shooting their foot when/if they want/need
to ;-) it's not a spec matter, still IMO


On Tue, Jan 14, 2014 at 11:37 AM, Kevin Smith <zenparsing at gmail.com> wrote:

>
>> If power users would like to compare via == when they are aware of
>> operator overload for used classes then I don't see any problem.
>>
>>
> If you know the operand types already, then there's no problem.  But in
> cases where you don't control the operand types how will you know the
> semantics that "==" will provide?  What does the following mean?
>
>     if (maybeCollection1 == maybeCollection2) { ... }
>
>
>> Operators overload worked for power users in many other languages and I
>> think if not abused it can be very handy.
>>
>
> In general, I agree.  But in the specific case of "==" I'm not sure we
> have a solid foundation to build upon.  How do you meaningfully overload a
> language element that, arguably, carries no useful meaning?
>
>
>>
>> Once again, just my 2 cents
>>
>
> Mine too - we need to wait for a proposal before going any further.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140114/a40fdc45/attachment-0001.html>


More information about the es-discuss mailing list