Hi, Sorry, somehow this slipped through my radar... > Today, I'm facing something surprising about BaseSingleFieldPeriod.equals(): > Days.ONE.equals(Period.days(1)) is false !
Yes, this can appear a little odd, and perhaps is not ideal. The problem arises when you try to define an interface that defines an equals policy. In doing so, like in collections, there are sometimes odd cases created. The PeriodType concept is not one I especially like in Joda-Time. It makes sense as a parameter to construct the Period object, but perhaps should not have been stored as part of the state. However, that would then affect the ability of the interface to define methods to extract the fields of a ReadablePeriod in a general way. ie. everything ends up being connected. There is certainly no way to change it now, due to backwards compatibility. However, JSR-310 should hopefully do something better. It would certainly be possible to write a method to compare two ReadablePeriods on non-zero fields. This would be a useful static utility method for Joda-Time itself to have. Stephen > According to this equals() JavaDoc : Compares this object with the specified > object for equality based on the value of each field. All ReadablePeriod > instances are accepted, but only those with a matching PeriodType can return > true. > > So, the documentation is consistent. But the question is: Why would a > Period.days(1) with all fields set to zero except "days" not equal the very > same Period defined by Days.ONE ? > > I understand the distinction here is that they have distinct period types. > An an example, Period.days(1).withMonths(1) is legal whereas > Days.ONE.withMonths(1) is not. > But this is about what those Period instances could become. Not about what > they really are. > > As a programmer, when I compare Period.days(1) ans Days.ONE, I'm interested > in comparing what those instances really mean. Not what constraints do apply > to them whatever they are. Those constraints are another matter, which I > could test separately by comparing the respective period types, if I need > to. > > More formally, in the current design, Period instances are split into > distinct equivalence classes made up by .equals() (which is an equivalence > relation), depending on the restrictions enforced by their PeriodType. > Instances of Days are one equivalence class, instances of Months are > another, etc. > > But those instance might actually mean the same as a regular Period instance > with standard PeriodType if the fields define the exact same period. What is > the reasonable need for creating distinct equivalence classes here? My point > here is that distinct period types is not one. > > /Benjamin Gandon > > > > > ------------------------------------------------------------------------------ > The demand for IT networking professionals continues to grow, and the > demand for specialized networking skills is growing even more rapidly. > Take a complimentary Learning@Cisco Self-Assessment and learn > about Cisco certifications, training, and career opportunities. > http://p.sf.net/sfu/cisco-dev2dev > _______________________________________________ > Joda-interest mailing list > Joda-interest@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/joda-interest > > ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 _______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
