You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Duncan Jones <dj...@apache.org> on 2014/09/26 12:32:06 UTC
[LANG] Thoughts on LANG-1039
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
Re: [LANG] Thoughts on LANG-1039
Posted by Duncan Jones <du...@wortharead.com>.
On 26 September 2014 14:53, Gary Gregory <ga...@gmail.com> wrote:
> Let's also think about what happens when you to an array into a Map.
>
> Does the fact that we are dealing with a reflection hashCode API mean it
> should give the same key that would be used if you put the array in a map?
>
> Gary
Hi Gary, I don't entirely understand the point you are making there -
would you mind explaining further?
In the meantime, the original posters of LANG-1039 have admitted they
don't actually have a use case for passing arrays to this method.
They've simply spotted the odd result when they do.
I remain convinced the reflective builder is fine as it is, but
perhaps the Javadoc could be slightly clearer. I'll look to make an
edit to that.
Duncan
>
> On Fri, Sep 26, 2014 at 7:10 AM, Michael Pigott <
> mpigott.subscriptions@gmail.com> wrote:
>
>> 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" <dj...@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
>> >
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> Java Persistence with Hibernate, Second Edition
> <http://www.manning.com/bauer3/>
> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
> Spring Batch in Action <http://www.manning.com/templier/>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [LANG] Thoughts on LANG-1039
Posted by Gary Gregory <ga...@gmail.com>.
Let's also think about what happens when you to an array into a Map.
Does the fact that we are dealing with a reflection hashCode API mean it
should give the same key that would be used if you put the array in a map?
Gary
On Fri, Sep 26, 2014 at 7:10 AM, Michael Pigott <
mpigott.subscriptions@gmail.com> wrote:
> 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" <dj...@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
> >
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [LANG] Thoughts on LANG-1039
Posted by Michael Pigott <mp...@gmail.com>.
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" <dj...@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
>