In that case, I guess JME is doing bitwise comparison? Ah, they are using compare()…
if (Float.compare(x,comp.x) != 0) return false;
if (Float.compare(y,comp.y) != 0) return false;
if (Float.compare(z,comp.z) != 0) return false;
…which is good in some cases, I guess. But it’s weird in the case of NaN.
If you did not find a Position you could also return null, might be more obvious to implement.
And if I am not mistaken Vector3f already hast approximatelyEquals or something (but maybe only in regards to the length because for 3d the tollerance could have different methods (Sum of deviation over the components or max deviation per component mainly)
Probably going into details here, but isn’t it always best to try to return the object type question, even if it’s empty - rather than null?
For example, if I expected a method to return an array, and my method couldn’t for some reason - I’d probably return an empty array, not null. I was always taught that it’s better to do that then just return null by default behavior. Same for string or even integers. Return an empty string or -1 (if that is outside the int bounds) if possible, but not null.
It depends… null is better because you didn’t create an object you will just throw away and comparing something to null is much faster than making a method call.
It’s quite common to return null for “unknown” but it can depend on the method semantics. For example, arrays and collections are arguably cases where you might return an empty collection… because ‘empty’ makes sense in this context. (Edit: and often the caller will want to iterate over it right away and you save them some trouble.)