Skip to content

MINOR: Generated classes should have standard equals#7709

Closed
cmccabe wants to merge 1 commit intoapache:trunkfrom
cmccabe:ilhc_equals
Closed

MINOR: Generated classes should have standard equals#7709
cmccabe wants to merge 1 commit intoapache:trunkfrom
cmccabe:ilhc_equals

Conversation

@cmccabe
Copy link
Copy Markdown
Contributor

@cmccabe cmccabe commented Nov 18, 2019

Previously, generates classes that were used as keys got non-standard
equals and hashCode functions which only checked the fields that were
part of their keys. This was confusing for people using those functions
in different contexts.

Instead, we should give ImplicitLinkedHashCollection and subclasses the
ability to use a separate function to compare and hash the key fields,
and generate standard equals and hashCode functions.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's better to do instanceof than this. The JVM folds the instanceof into the trap it needs to ensure JVM semantics.

Unite ImplicitLinkedHashCollection and ImplicitLinkedHashMultiCollection
into a single class.  It's simpler this way, and the code that needs to
avoid duplicates can do it through the API.

Fix the problem where inserting the same object into a collection twice
causes corruption.  This happened because due to the implicit linked
list, there was only one set of previous and next pointers.  We get
around this in this PR by duplicating the inserted object when this
situation arises.

Generated Message classes now have a duplicate() function which creates
a duplicate of the existing object, and a copy() method which sets all
values to those of another object of the same type.  Previously, we had
to resort to clunky serializing and then deserializing to copy message
objects.

Generated Message classes now always have an equals() function which
tests every field.  Previously, message classes used as keys had special
equals functions which only compared their key fields, which was
confusing.  We still support searching by the key because the find and
findAll functions now take a comparator argument.
@cmccabe
Copy link
Copy Markdown
Contributor Author

cmccabe commented Apr 26, 2020

Superseded by #8539

@cmccabe cmccabe closed this Apr 26, 2020
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.

2 participants