[xwiki-devs] [PROPOSAL] So what do we do about HashCodeBuilder parameters ?
Hi devs, Most Object#hashCode() are implemented using HashCodeBuilder. HashCodeBuilder provide an empty constructor and also allow setting "random" numbers. http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HEquals2FHashCodeandToStringimplementations does not really say anything about what do do and when currently so I would like to have a clear rule about it. On my side when I don't plan to use different types of objects in a hash key I usually simply use the empty HashCodeBuilder constructor. The only point of setting different numbers is when you might end up comparing different object types (and even in that case you have the #equals() safeguard anyway so it's mostly about performances in practice). So here is a proposal: it's OK to use empty HashCodeBuilder constructor except: * when overwriting the hachCode of a super class you should use different numbers than the super class (since there is big chance to have that super class used as a hash key) * as a best effect in general if you know that you are going to have several different types as hash key, try to make sure they use different random numbers, your proc will thank you :) WDYT ? -- Thomas Mortagne
Re: [xwiki-devs] [PROPOSAL] So what do we do about HashCodeBuilder parameters ?
Hi, > On 8 Dec 2017, at 11:12, Thomas Mortagne wrote: > > Hi devs, > > Most Object#hashCode() are implemented using HashCodeBuilder. > HashCodeBuilder provide an empty constructor and also allow setting > "random" numbers. > > http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HEquals2FHashCodeandToStringimplementations > does not really say anything about what do do and when currently so I > would like to have a clear rule about it. > > On my side when I don't plan to use different types of objects in a > hash key I usually simply use the empty HashCodeBuilder constructor. > The only point of setting different numbers is when you might end up > comparing different object types (and even in that case you have the > #equals() safeguard anyway so it's mostly about performances in > practice). > > So here is a proposal: it's OK to use empty HashCodeBuilder constructor > except: > * when overwriting the hachCode of a super class you should use > different numbers than the super class (since there is big chance to > have that super class used as a hash key) > * as a best effect in general if you know that you are going to have > several different types as hash key, try to make sure they use > different random numbers, your proc will thank you :) > > WDYT ? I don’t fully master the topic but I’m trusting you so +0 from me. Only comment is that it means there’s not a single way of writing our code and thus is not that easy to check. Thanks -Vincent > > -- > Thomas Mortagne
Re: [xwiki-devs] [PROPOSAL] So what do we do about HashCodeBuilder parameters ?
+0 Thanks, Marius On Fri, Dec 8, 2017 at 12:12 PM, Thomas Mortagne wrote: > Hi devs, > > Most Object#hashCode() are implemented using HashCodeBuilder. > HashCodeBuilder provide an empty constructor and also allow setting > "random" numbers. > > http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle# > HEquals2FHashCodeandToStringimplementations > does not really say anything about what do do and when currently so I > would like to have a clear rule about it. > > On my side when I don't plan to use different types of objects in a > hash key I usually simply use the empty HashCodeBuilder constructor. > The only point of setting different numbers is when you might end up > comparing different object types (and even in that case you have the > #equals() safeguard anyway so it's mostly about performances in > practice). > > So here is a proposal: it's OK to use empty HashCodeBuilder constructor > except: > * when overwriting the hachCode of a super class you should use > different numbers than the super class (since there is big chance to > have that super class used as a hash key) > * as a best effect in general if you know that you are going to have > several different types as hash key, try to make sure they use > different random numbers, your proc will thank you :) > > WDYT ? > > -- > Thomas Mortagne >
Re: [xwiki-devs] [PROPOSAL] So what do we do about HashCodeBuilder parameters ?
On Fri, Dec 8, 2017 at 11:33 AM, Vincent Massol wrote: > Hi, > >> On 8 Dec 2017, at 11:12, Thomas Mortagne wrote: >> >> Hi devs, >> >> Most Object#hashCode() are implemented using HashCodeBuilder. >> HashCodeBuilder provide an empty constructor and also allow setting >> "random" numbers. >> >> http://dev.xwiki.org/xwiki/bin/view/Community/JavaCodeStyle#HEquals2FHashCodeandToStringimplementations >> does not really say anything about what do do and when currently so I >> would like to have a clear rule about it. >> >> On my side when I don't plan to use different types of objects in a >> hash key I usually simply use the empty HashCodeBuilder constructor. >> The only point of setting different numbers is when you might end up >> comparing different object types (and even in that case you have the >> #equals() safeguard anyway so it's mostly about performances in >> practice). >> >> So here is a proposal: it's OK to use empty HashCodeBuilder constructor >> except: >> * when overwriting the hachCode of a super class you should use >> different numbers than the super class (since there is big chance to >> have that super class used as a hash key) >> * as a best effect in general if you know that you are going to have >> several different types as hash key, try to make sure they use >> different random numbers, your proc will thank you :) >> >> WDYT ? > > I don’t fully master the topic but I’m trusting you so +0 from me. Only > comment is that it means there’s not a single way of writing our code and > thus is not that easy to check. The problem is that It's not easy to have a single way to write our code here, if you want one it's going to be "it's OK to use empty constructor of HashCodeBuilder" and the rest will move somewhere like http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Performances#HMemory :) In practice those are more performances related advices because saying something like "all classes must use different numbers" is simply impossible to enforce/check in practice because it's way to hard to know if you are using unique numbers or not. > > Thanks > -Vincent > > >> >> -- >> Thomas Mortagne > -- Thomas Mortagne
Re: [xwiki-devs] [XWiki Day] BFD#157
Results: http://www.xwiki.org/xwiki/bin/view/Blog/Bug%20Fixing%20Day%20157. Thanks, Alex On Thu, Dec 7, 2017 at 9:00 AM, Alex Cotiugă wrote: > Hello devs, > > This Thursday is BFD#157: > http://dev.xwiki.org/xwiki/bin/view/Community/XWikiDays#HBugfixingdays > > Our current status is: > > * -10 bugs over 120 days (4 months), i.e. we need to close 28 bugs to have > created bugs # = closed bugs # > * -50 bugs over 365 days (1 year) > * -46 bugs over 500 days (between 1 and 2 years) > * -218 bugs over 1600 days (4.3 years) > * -671 bugs since the beginning of XWiki > > See https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 > > > Here's the BFD#157 dashboard to follow the progress during the day: > https://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=13930 > > Happy Bug Fixing Day, > Alex >
