Skip to content

Check nullity for __eq__ and __ne__ #734

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

pfeodrippe
Copy link

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

`__eq__` for `Array` checks for the lenght of `b`, but `b` could be `null`
@mentalisttraceur
Copy link

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
Copy link

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
Copy link

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
Copy link

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.

@JennaSys
Copy link
Collaborator

JennaSys commented Aug 4, 2024

Maybe related to #588

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants