Check nullity for __eq__ and __ne__

[pfeodrippe]

__eq__ for Array checks for the lenght of b, but b could be null

[mentalisttraceur]

I do not understand the reason for this special case. Should objects with custom equality checks not be allowed to decide if they are equal to null (and undefined)?

[mentalisttraceur]

What problems are caused by permitting null (or undefined) to pass through in here? Do they outweigh the possible benefits of being able to have a class which compares equal to them?

[mentalisttraceur]

These are genuine questions: I don't know, I haven't done enough work with Transcrypt to say.

But my intuition is that classes should be able to receive raw null and undefined in their custom comparison methods, because this is more flexible and obvious to me than a special case where those specific values bypass custom comparison logic.

[mentalisttraceur]

Also, possibly related: independent of this change, I don't understand why these built-in __eq__ and __ne__ functions are one-sided (they have a case for calling a.__eq__(b) but not a symmetric case for calling b.__eq__(a)).

Couple possibilities:

1. That's not implemented at all. If class A implements __eq__ and you do a comparison like native_js_object == instance_of_A, Transcrypt never tries instance_of_A.__eq__(native_js_object). That seems like such a profound gap in functionality, that I don't think that's likely to be the case.

2. That's implemented inside the .__eq__ and .__ne__ that are on the objects. If so, then I would expect an if(typeof b == 'object' && '__eq__' in b) check to happen in those methods before trying b.__eq__(a), and that should protect against any inherent problem with letting null or undefined fall through.