Discussion: Days.ONE.equals(Period.days(1)) is false, but should be true

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Discussion: Days.ONE.equals(Period.days(1)) is false, but should be true

Benjamin Gandon
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(): Days.ONE.equals(Period.days(1)) is false !

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Discussion: Days.ONE.equals(Period.days(1)) is false, but should be true

jodastephen
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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...