commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Pigott <mpigott.subscripti...@gmail.com>
Subject Re: [LANG] Thoughts on LANG-1039
Date Fri, 26 Sep 2014 11:10:45 GMT
Hi Duncan,
    Does it make sense to create a method specifically for array types,
which calls reflectonHashCode on each element to compute a final hash code?
This would solve the poster's problem and avoid polluting
reflectionHashCode with the behavior.

Regards,
Mike
On Sep 26, 2014 6:32 AM, "Duncan Jones" <djones@apache.org> wrote:

> Hi folks,
> I'd welcome someone else's viewpoint on LANG-1039. The question is: what
> should HashCodeBuilder.reflectionHashCode() do when given an array object
> as input.
>
> My argument is that the intended use of this method is for overriding
> Object.hashCode() and so it should never be the case than an array object
> is passed to this method. (It will always be "this").
>
> The complaint from the poster is that arrays return the result 17. This is
> because arrays have no fields, so our reflection logic doesn't find
> anything to add to the cumulative hash code.
>
> I'm in favour of saying this isn't a problem, but it might be worth adding
> something extra to the Javadocs to make it clearer how this method is
> intended to be used and how it works. Something like "If object has no
> fields, the result will be a constant value (default = 17)" or similar.
>
> However, we could extend the method to recognise array types and return a
> hashcode for the array.
>
> I welcome thoughts on the matter.
>
> Kind regards,
>
> Duncan
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message