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

[Stephen Colebourne]

On 4 February 2013 01:09, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> M7 is destined for the developer preview and after that even minor changes
> will not be welcome and we're out of time.
> So I'd push for the major change to be in M7.

So be it.

> BTW, there are a few stray static methods in Chronology to support
> date.atTime()
> and creating ChronoZonedDateTime instances.  With static methods in
> interfaces
> is there a better place for them?

Remove ChronoDateImpl.atTime()  (pointless override of ChronoLocalDate)
Make Chronology.dateTime(ChronoLocalDate<R> date, LocalTime time)
package scoped.
Add Javadoc (useful for those reading code rather than HTML Javadoc)
     * <p>
     * This method is called from {@link ChronoLocalDate#atTime(LocalTime)}.
     * Application code, and implementations of this class, should use
     * {@code atTime} to create a {@code ChronoLocalDateTime}.

> There might also be a case for removing getEra() from ChronoLocalDate
> as it adds less value now (it could still be on JapaneseDate and
> others where it matters).
> The era is still needed to be able to pass to Chronology to create dates.

Or getEra() could be replaced by Era.from() static method. But its
more useful to chrono-level (c) users as is.

On 4 February 2013 04:27, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> Cleaned up the methods on the Chrono and calendar types and updated the
> javadoc.
>
> But the generics on ChronoLocalDate will need to be restored.
> Without  them it is not possible to write a library than can return
> the same type of date passed in.    Something as simple as:
>
> <D extends ChronoLocalDate> D next(D date) {
> !    D next = date.plus(2, DAYS);
>     return next;
> }
>
> fails because the type of date.plus is always ChronoLocalDate.

I'm OK with that if you prefer it that way. Removing generics from
Chronlogy/Era and making the date clases public is a net win I think.

I reviewed the Javadoc.
The main issue is that the of() factory methods on the 4 date classes
are inconsistent. The full set of methods would be
1) now()
2) now(ZoneId)
3) now(Clock)
4) from(TemporalAccessor)
5) of(y,m,d)
6) of(e,y,m,d)
7) ofYearDay(y,d)
8) ofYearDay(e,y,d)
9) parse(CharSeq)
10) parse(CharSeq, DTFormatter)

I think that from the perspective of (b) user, they definitely want
(4) and (5) and probably (1) (2) and (3).

(6), (7) and (8) seem like ones they could live without, except on
JapaneseDate where (6) would be needed.

The parse methods (9) and (10) would also be desirable, but could
probably be lived without so long as (4) is present to use as a method
reference.

The implementations of these methods could delegate to the matching
chronlogy for simplicity.

Stephen