Skip to content
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

Unit equals implementation is "bad" #82

Open
Bytekeeper opened this issue Nov 5, 2018 · 3 comments
Open

Unit equals implementation is "bad" #82

Bytekeeper opened this issue Nov 5, 2018 · 3 comments

Comments

@Bytekeeper
Copy link
Collaborator

I guess the code is copied from BWMirror, which only compares the ids to determine equality.
This is rather bad for BWAPI4J where a type change also results in a new Unit object with the same id.

If, for example used as a Map key the following code or similar might be used:

for (Entry<Unit,Something> u: Units.entrySet()) {
...u.getKey().getPosition().getDistance(u.getValue().goal)...

Now, getKey will always return the initial unit, for example a larva... but now it's a zergling! The position of the larva will never be updated and thus this usage is in vain.

I think the equals method should include the unit type too at the very least. Opinions?

@Jabbo16
Copy link
Contributor

Jabbo16 commented Nov 6, 2018

I agree, I discovered some problems recently because my maps keys (Unit) are not updated when the units morph.

@JasperGeurtz
Copy link

JasperGeurtz commented Nov 6, 2018

Tanks however stay the same class even if their unittype changes (siege/unsiege), so just got to be careful with that.

@Bytekeeper
Copy link
Collaborator Author

@JasperGeurtz True, but I think that's "safe". The main problem here is the types that actually change classes. Some code could hold references and not detect that the instance is invalid.

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

No branches or pull requests

3 participants