[
https://issues.apache.org/jira/browse/LANG-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295764#comment-14295764
]
Thibault Kruse commented on LANG-1084:
--------------------------------------
Thanks for explaining your perspective.
I agree not all cases would be found this way, but that might still better than
none.
However the explicit form is possible to catch the case you mention:
Test.equalT<Foo, Foo>(getFooX(), getFooY());
The method is not symmetric, but neither is any other such equals method
symmetrical, such as java.util.Objects.equals();
class Animal {
// Rule 7: all animals are equal
public boolean equals(Object obj) {
return obj != null;
}
}
Animal a = new Animal(); Object o = new Object();
assert Objects.equals(a, o);
assert !Objects.equals(o, a);
Assymetry at compile time is better than assymetry at runtime, of course.
Some variations are also possible, as
public static <T> boolean equalT(T t1,T t2) // more restrictive
public static <T, U extends T, V extends T> boolean equalT2(U u,V u) // too
lenient without explicit type parameters
I cannot tell whether this conept fits into LANG, so feel free to close based
on your best judgement.
> ObjectUtils should have type-safe equals() method
> -------------------------------------------------
>
> Key: LANG-1084
> URL: https://issues.apache.org/jira/browse/LANG-1084
> Project: Commons Lang
> Issue Type: Improvement
> Reporter: Thibault Kruse
> Priority: Minor
>
> Commonly implementation of Object.equals() perform an instanceof check before
> casting and then comparing properties.
> That means that any code like a.equals(b) does not imply any compile-time
> type checking.
> However it can be very desirable to check types at compiletime in many
> (though not all) situations. E.g. consider this code:
> Person a = getPersonViaX();
> Person b = getPersonViaY();
> assert !a.equals(b);
> this code is typesafe at compiletime. If getPersonViaY() changes the return
> type to something that does not extend Person, this will fail to compile.
> Now consider this refactored:
> assert !getPersonViaX().equals(getPersonViaY());
> In this case the change to getPersonViaY() would go unnoticed, both at
> compiletime AND at runtime (if equals merely returns false in the instanceof
> check of the most common equals method design).
> Based on this blogpost:
> http://rickyclarkson.blogspot.de/2006/12/making-equalsobject-type-safe.html
> I suggest a typesafe equals method for situations like above:
> public static <T,U extends T> boolean equalT(T t,U u)
> { return t.equals(u); }
> and possible a typesafe notEquals method as well.
> I am dispassionate about naming of the method, might as well be
> typeSafeEquals() or whatever fits best into apache commons.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
