Re: [threeten-develop] Feedback on the threeten apis

[Stephen C. <sco...@jo...>]

On 1 May 2012 22:44, Roger Riggs <Rog...@or...> wrote:
> The algorithm would be used in an application on a tablet, phone, or desktop
> to
> show the user the date of the next payday and tell how many days until
> payday.
> Payday is the 15th or last day of the month unless it falls on a weekend and
> then it is the previous Friday.

 import static DayOfWeek, DateAdjusters;

 LocalDate today = LocalDate.now();
 LocalDate payday = (today.getDayOfMonth() <= 15 ?
     payday.withDayOfMonth(15) : payday.with(lastDayOfMonth()));
 if (payday.getDayOfWeek() == SATURDAY || payday.getDayOfWeek() == SUNDAY) {
   payday= payday.with(previous(FRIDAY));
 }

or, with a nice packaged JDK 8 solution:

 LocalDate payday = LocalDate.now().with(DateUtils::nextPayday)

(note this code ignores Friday holidays. Were a WeekendRules class to
be added - see git - this would be even easier)


> LocalDate's weekday enums made it awkward to compute and skip back to
> Friday.
>
>  int pastFriday = payday.getDayOfWeek().getValue() -
> DayOfWeek.FRIDAY.getValue();
>         if (pastFriday > 0) {
>             payday = payday.minusDays(pastFriday);
>         }

Using day-of-week in this way is open to bugs as it requires you to
know what the numbers allocated to the day-of-week are. A key point of
the new API (as discussed practiclly from day one) is to avoid using
numeric values for day-of-week for the main ISO case. (Which is why I
won't add a getDayOfWeek() returning an int).

As shown above, the previous Friday is actually really easy:
 date = date.with(DateAdjusters.previous(FRIDAY));

> The compound condition on the date and the day of the week are not supported
> by the adjusters.  Of course, any number of special cases could be provided
> but the developer still has to look/know.
>
> The LocalDate last day of the month seems to deserve some special treatment.
> How about withDay(-1) or withDay(-n) to compute from the end of the month.

DateAdjusters are not an optional part of the API, they are key to
writing "nice" readable and maintainable code that reads like the
algorithm:
 date = date.with(DateAdjusters.lastDayOfMonth());

Java does not support a -1 convention on java.util.List or
java.lang.String either.

> For LocalDate, computing the number of days until payday isn't too bad
> once you find the pieces of the API but they are not that easy to find:
>     return LocalDateUnit.DAYS.between(payday, date).getAmountInt();

By all means suggest an alternative, but this is a very effective way
to implement this functionality (in bytecode and API weight terms).

One thing to bear in mind is StackOverflow where a knowledge-base of
best practices soon builds up with a little care and attention.
http://stackoverflow.com/questions/tagged/jodatime

310 is moving the abstraction level up, just like moving from C to Java.

> For the ChronoDate version the problems included:

To me, this is a false test. Do the calculation in ISO and then output
it in the other calendar. Hardly anyone globally is going to get paid
according to a schedule derived from another calendar.

> No definition of the days of the week, no symbolic names for MONDAY..SUNDAY
> 1..7.
True. But as I've mentioned before, I'm not certain that alternate
calendar systems should support day-of-week. If they do, then the
constants should be added.

> Computing the number of days until payday  or days between dates was
> not directly available but computable the hard way from day-of-year and
> handling wrap-around.
> But the number of days in the year was not directly available and had to be
> computed.
>
>  int daysinyear =
> date.withDayOfMonth(1).withMonthOfYear(1).plusYears(1).minusDays(1).get(ChronoDateField.DAY_OF_YEAR);

This (meta information) is intended to be available via the field.
Right now that needs a little more work.

Stephen