Operator overloading for non-value objects

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Jan 14 11:20:36 PST 2014

it's transparent for the user and your example assumes nobody overwrote

That example is a crazy assumption for many reasons and the correct check
would be eventually via `toString.call(object)`, well still hoping nobody
changed native `toString`, of course, but you know what I mean.

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.

Operators overload worked for power users in many other languages and I
think if not abused it can be very handy.

Once again, just my 2 cents

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

>> In JS world we are "use to" compare via === so that when == is used
>> instead we are usually in "power user land", I don't see any conceptual
>> shenanigans in doing something like above code.
> Only power users use "==" because it has weird conversion semantics that
> are hard to internalize.  "==" doesn't map to any simple relational
> concept, certainly not "equality":
>     ({}) == "[object Object]"; // true
> So if a user is going to overload "==", are they going to maintain those
> bizarre semantics?  If so, then crazy-pants.  If not, then it seems like we
> have introduced a hazard into code that is generic with respect to the
> types of operands to which "==" is applied.  Sometimes crazy conversion
> semantics, sometimes sensible equality semantics.
> I'll stop there, because I don't know the details of the proposal.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140114/48996606/attachment.html>

More information about the es-discuss mailing list