Greetings fellow monkeys,
I just stumbled upon the fact that com.jme3.math.Transform has no equals-method. Is there a reason for that?
If no i would request it.
regards,
ceiphren
@ceiphren said: Greetings fellow monkeys,I just stumbled upon the fact that com.jme3.math.Transform has no equals-method. Is there a reason for that?
If no i would request it.
regards,
ceiphren
Curious: what do you need it for?
@pspeed: Currently I need it in a unit test where I compare saved game data with default values (to see if the saving works). To make thinks easier I’m running over the equals-method of every object.
Always hard to define equals on float values. For the save/restore scenario ‘==’ should maybe be alright. But in other scenarios, what would be the epsilon? If it is component-wise, i.e. Math.abs(this.x-other.x) < epsilon, what is the accumulated error, is it equals enough? So yeah, maybe just use ‘==’ and write so in the javadoc is the least surprising solution 
@jmaasing: yep, that would be what I would expect. If an epsilon is needed it should be defined explicitly in the current compare case. In every other case, a float compare should be equal if the floats are completely equal.
As a rule, .equals() should be == for things like float. Otherwise, it’s not .equals() it’s something else.
…as an example, it’s wrong to implement .equals() without implementing .hashCode() and I don’t even want to think of how one would generate a good hashcode other than from the bits representations of float… which would only be the same for ==.