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
`Object.prototype.toString/valueOf`

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