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

[Roger Riggs]

Hi,

More cleanup of the factory methods and restored the generics
to enable the use case below.

Updated; please review:

javadoc:
http://cr.openjdk.java.net/~rriggs/javadoc-chrono-generics-191/
webrev:
http://cr.openjdk.java.net/~rriggs/webrev-chrono-generics-191/

If this is close, I'll merge with the other pending changes
and move the calendars to java.time.chrono.

Then we can put it out for review and only do fine tuning until the
push early next week.

inline...

On 2/4/2013 6:33 AM, Stephen Colebourne wrote:
> On 4 February 2013 01:09, Roger Riggs<Roger.Riggs at oracle.com>  wrote:
>
>> 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.
Even the package private method seemed unnecessary.
The implemenetation of ChronoLocalDate.atTime can call the 
ChronoLocalDateTimeImpl directly. Going through the chronology isn't
does add any value.

> 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.
yes,
>
> 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.
ok, I implemented 1, 2,3,4, 5 and 6 for Japanese.
>
> 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.
Yes, took the simple implementation path for now.

Roger