uschindler commented on code in PR #16414:
URL: https://github.com/apache/lucene/pull/16414#discussion_r3789518177
##########
lucene/core/src/java/org/apache/lucene/util/automaton/StateSet.java:
##########
@@ -121,4 +121,36 @@ long longHashCode() {
hashUpdated = true;
return hashCode;
}
+
+ @Override
+ public boolean equals(Object o) {
+ if (this == o) return true;
+ if (!(o instanceof IntSet that)) {
+ return false;
+ }
+ if (size() != that.size()) {
+ return false;
+ }
+ if (longHashCode() != that.longHashCode()) {
+ return false;
+ }
+ if (that instanceof FrozenIntSet frozen) {
Review Comment:
I have not yet closely looked into that but we can indeed enforce correct
behavior with sealed and final classes. Basic Ann the common base class of the
only two final implementations should be marked sealed with the only two
allowed subclasses.
Then we can convert the part after the initial instance of check (that
ensures classes are compatible at all, so the check for the sealed base class)
to a simple pattern switch *without* a default case.
This ensures that if somebody adds a new implementation that compilation of
the equals method will definitely fail.
Read more here, this summary is exactly explaining how the pattern switch
and the sealed classes work together:
https://medium.com/@masha.komarkofffa/mastering-sealed-classes-switch-pattern-matching-in-java-write-safer-smarter-code-8700e69a3f6f
So I strongly agree to cleanup the class hierarchy in this case so we ensure
that we get what we expect.
In general we should make more use of sealed classes, especially for public
classes. Esecially those where performance matters with virtual calls. If there
are only 2 subclasses allowed, hotspot may make better decisions.
Please keep me in the loop, I will assist!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
