commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sebb (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LANG-1084) ObjectUtils should have type-safe equals() method
Date Wed, 28 Jan 2015 17:20:34 GMT

    [ https://issues.apache.org/jira/browse/LANG-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14295414#comment-14295414
] 

Sebb commented on LANG-1084:
----------------------------

Not sure that is going to be very usable, as the API is assymetric.

For example:

{code}
Integer i = 1;
Number n = i;
Test.equalT(n, i);
Test.equalT(i, n); // Compiler error
{code}

The contract of equals() requires symmetry; this is not symmetric.

I don't think it makes sense to try to bundle type checking into the equals method.

Although the proposed method will detect some changes of return type, it won't detect them
all - e.g. both getPersonViaX() and getPersonViaY() are both changed to a different mutually
compatible type.

Sorry, but I don't think this belongs in LANG

> 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)

Mime
View raw message