Hello, Roger!
Thank you for looking at my proposal.
RR> What are the use cases?
It could be used to generate some per-day/per-month/per-year reports.
For example, consider you have a collection of Deal objects, each with
LocalDate:
List<Deal> deals;
Using Java-8 you can easily group them by date:
Map<LocalDate, List<Deal>> map = deals.stream()
.collect(groupingBy(Deal::getDate));
Now suppose you want to know how many deals you have for each day in
the current month (including days when there are no deals). Using the
proposed API you may write:
YearMonth.now().days()
.map(date -> date+": "+map.getOrDefault(date,
Collections.emptyList()).size()+" deal(s)")
.forEach(System.out::println);
RR> Does it need to be more convenient?
RR> It seems relatively easy to do in application code.
It's relatively easy, but it's necessary to refer to the temporal
object twice. Here's how it could be done now without creating
additional methods:
IntStream.range(1, YearMonth.now().lengthOfMonth())
.mapToObj(YearMonth.now()::atDay)
.map(...).forEach(...)
Such code may break when executed during the month change, so to make
it robust you should introduce a variable:
YearMonth now = YearMonth.now();
IntStream.range(1, now.lengthOfMonth())
.mapToObj(now::atDay)
.map(...).forEach(...)
Of course the static method could be introduced into some utility
class in the application:
public class DateStreams {
public static Stream<LocalDate> days(YearMonth ym) {
return IntStream.range(1, ym.lengthOfMonth()).mapToObj(ym::atDay);
}
}
And used like this:
DateStreams.days(YearMonth.now())
.map(date -> date+": "+map.getOrDefault(date,
Collections.emptyList()).size()+" deal(s)")
.forEach(System.out::println);
But having it in the JDK looks more natural. Especially given the fact
that java.time classes are final, so cannot be extended by some
third-party library.
RR> Could there be a more general form that would be as useful but add fewer
RR> methods?
Well for convenient use I cannot imagine how to reduce the number of
methods. It's possible to omit months() and days() and replace
year.months() with something like this:
year.atMonth(1).monthsUntil(year.plusYears(1).atMonth(1))
But it's even worse than not using the new API at all:
IntStream.range(1, 12).mapToObj(year::atMonth)
With best regards,
Tagir Valeev.
RR> Roger
RR> On 12/10/2015 11:31 AM, Tagir F. Valeev wrote:
>> Hello!
>>
>> Currently it seems that java.time package does not use Stream API in
>> any way. I think it would be nice to add some methods which produce
>> the streams. For example:
>>
>> - in class Year:
>>
>> // Returns sequential ordered stream of all months within this Year:
>> Stream<YearMonth> months();
>> // Returns sequential ordered stream of all days within this Year:
>> Stream<LocalDate> days();
>> // Returns sequential ordered stream of all years starting from this
>> // Year until the supplied year, exclusive
>> Stream<Year> yearsUntil(Temporal endExclusive);
>>
>> - in class YearMonth:
>>
>> // Returns sequential ordered stream of all days within this YearMonth:
>> Stream<LocalDate> days();
>> // Returns sequential ordered stream of all months starting from this
>> // YearMonth until the supplied YearMonth, exclusive
>> Stream<YearMonth> monthsUntil(Temporal endExclusive);
>>
>> - in class LocalDate:
>>
>> // Returns sequential ordered stream of all months starting from this
>> // LocalDate until the supplied LocalDate, exclusive
>> Stream<LocalDate> daysUntil(Temporal endExclusive);
>>
>> The implementation of these methods could be quite simple. For example:
>>
>> class Year {
>> public Stream<LocalDate> days() {
>> return IntStream.rangeClosed(1, length()).mapToObj(this::atDay);
>> }
>> }
>>
>> What do you think?
>>
>> With best regards,
>> Tagir Valeev.
>>
