-
Notifications
You must be signed in to change notification settings - Fork 24.8k
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
Use pattern variables for instanceof for type casting in equals #84315
Conversation
36fbd57
to
aa45195
Compare
aa45195
to
1f5b9b3
Compare
Pinging @elastic/es-core-infra (Team:Core/Infra) |
How concerning is this? Should we be being this to Core/Infra for discussion, before we change 800+ classes? I do think this PR is too big to review. If we want to proceed, we should break this down into smaller chunks. |
I'm okay to breaking this PR in multiple chunks. I believe it's not very concerning since all the "abstract" classes have children which override the |
9ca893a
to
d27452f
Compare
d27452f
to
f8bc92a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer not to do this, for two reasons:
- equals is then no longer symmetric. Suppose you have class
B
extends classA
and corresponding objectsb
anda
. If you doa.equals(b)
, it could be true, whereas b.equals(a) would not be. - The
equals
generated by IDEA differs from this. We thus have to hand-craft equals, which is error-prone.
Thank you Henning! I actually was going to close the PR exactly for these both reasons. I found that there are too many side effects for going from |
Leverage the JEP 394 and express type casting and the equality check as a single expression.
The biggest issue seems to be that using
instanceof
instead ofgetClass
actually can change the semantic ofequals
for non-final classes: two different children of the same parent can be equal if they don't override parent'sequals
.