RFR:8146218: Producing streams in java.time?

[Stephen Colebourne]

On 27 January 2016 at 15:13, Roger Riggs <Roger.Riggs at oracle.com> wrote:
> On 1/26/2016 8:57 AM, Stephen Colebourne wrote:
>> Thus, adding the ChronoLocalDate methods later will make two additional
>> methods available on LocalDate (as they will not override).
>
> Since all the calendars are built on the same 24hour days and epochDays, the computations
> result would be the same regardless of the Chronology.
>
> The existing LocalDate.until, compareTo, isBefore, isAfter, isEqual methods already use the
> ChronoLocalDate argument type to avoid having double the signatures.
>
> Modifying the type of the argument to be ChronoLocalDate would not modify the semantics
> and would make it possible to avoid extra methods in the future.
>
> I recommend changing the argument to ChronoLocalDate be consistent with the existing
> until method to keep the option open for a possible addition to ChronoLocalDate

The LocalDate::datesUntil(ChronoLocalDate) method internals would be
unaffected as it operates off toEpochDay(). Worth noting that an
abstraction on the ChronoLocalDate interface would have to return
Stream<? extends ChronoLocalDate>.

A LocalDate::datesUntil(ChronoLocalDate, Period) method would however
contain a mixture of Chrono and ISO specific types. Given how the
internals of the method depend on access to Period specific concepts
abstracting to ChronoPeriod would not be pleasant (if possible) As
such, this signature seems unwise.

But that gives two types of signature - an abstracted one and a specific one:
LocalDate::datesUntil(ChronoLocalDate)
LocalDate::datesUntil(LocalDate, Period)

Again, it isn't clear that is better.
Stephen