[threeten-dev] [threeten-develop] Reconsidering generics on Chrono classes

[Stephen Colebourne]

I've taken a quick look. It seems that the generics have changed from
Chronology to date class, which strikes me as different rather than
better. Can you give any examples where this makes user code simpler?
And why you see it as an improvement?

My thoughts in #191 were trying to remove generics entirely from
Chronology and Era. My theory is that a user will work in one of three
ways
a) only with ISO, and thus with concrete types
b) only with a non-ISO calendar system, and thus a public XxxDate class
c) only at the abstract chrono-level

If there is a public XxxDate class, then (a) and (b) users are happy
(with the exception of (b) user accessing
ChronoLocalDateTime/ChronoZonedDateTime)

The real question is whether those (c) users working with the abstract
chrono-level care about whether the calendar system object they are
passing around is the same as that of another object (which either
form form generics allows). The question would seem partly answered by
j.u.Calendar, which doesn't restrict or generify by calendar system.

We also have Oracle Globalization team comments that they would always
create a date in the abstract, without knowledge of the calendar
system. Given this, there is no way to ever populate the generic
argument from typical chrono-level usage. Thus whether the generic it
is a Chronology or a ChronoLocalDate is irrelevant.

No generics on any of the five key classes (Chronology, Era,
ChronoLocalDate, ChronoLocalDateTime, ChronoZonedDateTime) requires
three public classes for each calendar system, which seems overkill.

A more practical/balanced approach would be:
- Chronology - no generics
- Era - no generics
- ChronoLocalDate - no generics
- ChronoLocalDateTime<D extends ChronoLocalDate>
- ChronoZonedDateTime<D extends ChronoLocalDate>

With this approach, chrono-level users (c) would use ungenerified
types Chronology/Era/ChronoLocalDate and wildcarded
ChronoLocalDateTime<?> and ChronoZonedDateTime<?>. Whereas (b) users
would use XxxChronology, Era, XxxDate, ChronoLocalDateTime<XxxDate>
and ChronoZonedDateTime<XxxDate>.

For me, the question here was whether this approach could be made to
work, as it seemed to be the approach that met the needs of users (a),
(b) and (c) best.

Stephen


On 2 February 2013 21:43, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Hi,
>
> I took another look at the use of generics in the Chrono classes and
> drafted an alternative that is an improvement.
>
> Issue #191 mentions that the generics do not add (enough) value.
>
> Changing the parameter from Chronology to the concrete ChronoLocalDate type
> is more usable for the case where the concrete date type is being used
> deliberately
> and enable greater fluency.
>
> Exposing the concrete date types along with the Chronology types makes
> it easier
> to write calendar specific applications and makes code using
> ChronoLocalDateTime
> and ChronoZonedDateTime more fluent.
>
> Take a look at the comment.
> javadoc:
>     http://cr.openjdk.java.net/~rriggs/javadoc-chrono-generics-191/
> webrev:
>     http://cr.openjdk.java.net/~rriggs/webrev-chrono-generics-191/
>
> This is not ready to commit, though the functionality of the local date
> classes is stable, the javadoc needs improvement.
> In particular, the exposure of useful methods in the javadoc of each class
> is uneven since some are inherited and only appear in the inherited section
> of the javadoc.
>
> Thanks, Roger
>
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_jan
> _______________________________________________
> threeten-develop mailing list
> threeten-develop at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/threeten-develop