Hello,
I'm new to this list, so I'll briefly introduce myself: I'm Benjamin, a
Java Architect in Paris.
I've been using joda-time for 2 years in a couple of professional
projects. I know the jodat-time library from the inside, having extended
the library with two convenient Partial subtypes: WeekdayHourMinute that
proved being useful when enforcing strict definition of points in time
in a week-based (always repeating) calendar, and YearlyRepeatableDate
witch was useful to define holidays in a unique way: some occur at fixed
YMD dates, others not (though this class doesn't bring a elegant
solution to how model complex holidays rules).
So, I usually like the consistent design of the library. Professional.
Today, I'm facing something surprising about
BaseSingleFieldPeriod.equals()
<http://joda-time.sourceforge.net/api-release/org/joda/time/base/BaseSingleFieldPeriod.html#equals%28java.lang.Object%29>:
Days.ONE.equals(Period.days(1)) is false !
According to this equals() JavaDoc
<http://joda-time.sourceforge.net/api-release/org/joda/time/base/BaseSingleFieldPeriod.html#equals%28java.lang.Object%29>
: /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
<http://en.wikipedia.org/wiki/Equivalence_relation#Equivalence_class>
made up by .equals() (which is an equivalence relation
<http://en.wikipedia.org/wiki/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
