RFR:8146218: Producing streams in java.time?

[Roger Riggs]

Hi Stephen, Tagir,

On 1/27/2016 10:30 AM, Stephen Colebourne wrote:
> 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>.
Right,  Interestingly, none of the tests explicitly depend on the return 
type of Stream<LocalDate>
and only use methods that are in ChronoLocalDate.   (Based on a quick 
prototype).

But its enough to suggest that there should be some additional test or 
use of the compile time types.

A Stream<ChronoLocalDate> would be inconvenient and counter intuitive.
That's enough of a reason for me to keep the current signatures.

Thanks for the comments, Roger


>
> 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