|
[hidden email] wrote:
> Author: doogie > Date: Wed Feb 17 17:23:39 2010 > New Revision: 911089 > > URL: http://svn.apache.org/viewvc?rev=911089&view=rev > Log: > Rename millis parameters everywhere to milliseconds. Also rename the > millis method. At this point, I'm mostly done with TimeDuration. However, there's one more thing I have to do. The contract for java.lang.Object says that if you implement equals, you must implement hashCode against the same set of fields. TimeDuration doesn't currently do this. So, while trying to figure out how to do that exactly, I started adding some helper methods to UtilObject to make hashCode of multiple fields easier. Before that happened tho, I decided to write full test cases for UtilObject. So, TimeDuration and UtilObject now have full coverage. |
|
Adam Heath wrote:
> [hidden email] wrote: >> Author: doogie >> Date: Wed Feb 17 17:23:39 2010 >> New Revision: 911089 >> >> URL: http://svn.apache.org/viewvc?rev=911089&view=rev >> Log: >> Rename millis parameters everywhere to milliseconds. Also rename the >> millis method. > > At this point, I'm mostly done with TimeDuration. However, there's > one more thing I have to do. The contract for java.lang.Object says > that if you implement equals, you must implement hashCode against the > same set of fields. TimeDuration doesn't currently do this. > > So, while trying to figure out how to do that exactly, I started > adding some helper methods to UtilObject to make hashCode of multiple > fields easier. Before that happened tho, I decided to write full test > cases for UtilObject. Thank you for all your work! |
|
In reply to this post by Adam Heath-2
Adam Heath wrote:
> [hidden email] wrote: >> Author: doogie >> Date: Wed Feb 17 17:23:39 2010 >> New Revision: 911089 >> >> URL: http://svn.apache.org/viewvc?rev=911089&view=rev >> Log: >> Rename millis parameters everywhere to milliseconds. Also rename the >> millis method. > > At this point, I'm mostly done with TimeDuration. However, there's > one more thing I have to do. The contract for java.lang.Object says > that if you implement equals, you must implement hashCode against the > same set of fields. TimeDuration doesn't currently do this. > > So, while trying to figure out how to do that exactly, I started > adding some helper methods to UtilObject to make hashCode of multiple > fields easier. Before that happened tho, I decided to write full test > cases for UtilObject. > > So, TimeDuration and UtilObject now have full coverage. By the way, now that I fixed the epoch bug, don't you think we can put advanceCalendar back the way it was? The units argument will always be positive now. |
|
In reply to this post by Adrian Crum
Adrian Crum wrote:
> Adam Heath wrote: >> [hidden email] wrote: >>> Author: doogie >>> Date: Wed Feb 17 17:23:39 2010 >>> New Revision: 911089 >>> >>> URL: http://svn.apache.org/viewvc?rev=911089&view=rev >>> Log: >>> Rename millis parameters everywhere to milliseconds. Also rename the >>> millis method. >> >> At this point, I'm mostly done with TimeDuration. However, there's >> one more thing I have to do. The contract for java.lang.Object says >> that if you implement equals, you must implement hashCode against the >> same set of fields. TimeDuration doesn't currently do this. >> >> So, while trying to figure out how to do that exactly, I started >> adding some helper methods to UtilObject to make hashCode of multiple >> fields easier. Before that happened tho, I decided to write full test >> cases for UtilObject. > > Thank you for all your work! I don't need thanks. What I would like, however, is for people to start doing things similiar to what I do. I try to provide examples of how to work the with community software. |
|
In reply to this post by Adrian Crum
Adrian Crum wrote:
> Adam Heath wrote: >> [hidden email] wrote: >>> Author: doogie >>> Date: Wed Feb 17 17:23:39 2010 >>> New Revision: 911089 >>> >>> URL: http://svn.apache.org/viewvc?rev=911089&view=rev >>> Log: >>> Rename millis parameters everywhere to milliseconds. Also rename the >>> millis method. >> >> At this point, I'm mostly done with TimeDuration. However, there's >> one more thing I have to do. The contract for java.lang.Object says >> that if you implement equals, you must implement hashCode against the >> same set of fields. TimeDuration doesn't currently do this. >> >> So, while trying to figure out how to do that exactly, I started >> adding some helper methods to UtilObject to make hashCode of multiple >> fields easier. Before that happened tho, I decided to write full test >> cases for UtilObject. >> >> So, TimeDuration and UtilObject now have full coverage. > > By the way, now that I fixed the epoch bug, don't you think we can put > advanceCalendar back the way it was? The units argument will always be > positive now. Yeah, I saw what you did. I was about to commit my flood, but you just beat me. There is still full coverage, however, which means my version of the fix is still being run(all lines, all branches). I haven't had time to try and remove it and see if everything still succeeds. It might be that there isn't enough testing, and your fix actually fixes something else. |
|
Adam Heath wrote:
> Adrian Crum wrote: >> Adam Heath wrote: >>> [hidden email] wrote: >>>> Author: doogie >>>> Date: Wed Feb 17 17:23:39 2010 >>>> New Revision: 911089 >>>> >>>> URL: http://svn.apache.org/viewvc?rev=911089&view=rev >>>> Log: >>>> Rename millis parameters everywhere to milliseconds. Also rename the >>>> millis method. >>> At this point, I'm mostly done with TimeDuration. However, there's >>> one more thing I have to do. The contract for java.lang.Object says >>> that if you implement equals, you must implement hashCode against the >>> same set of fields. TimeDuration doesn't currently do this. >>> >>> So, while trying to figure out how to do that exactly, I started >>> adding some helper methods to UtilObject to make hashCode of multiple >>> fields easier. Before that happened tho, I decided to write full test >>> cases for UtilObject. >>> >>> So, TimeDuration and UtilObject now have full coverage. >> By the way, now that I fixed the epoch bug, don't you think we can put >> advanceCalendar back the way it was? The units argument will always be >> positive now. > > Yeah, I saw what you did. I was about to commit my flood, but you > just beat me. There is still full coverage, however, which means my > version of the fix is still being run(all lines, all branches). I > haven't had time to try and remove it and see if everything still > succeeds. It might be that there isn't enough testing, and your fix > actually fixes something else. Never mind. I just re-read your code comments and realized what you're doing is correct. |
| Free forum by Nabble | Edit this page |
