Re: [threeten-develop] Pirate strategvadoc

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

On 1 May 2012 20:10, Xueming Shen <xue...@or...> wrote:
> I might have been asking the wrong question. Let me try again:-) The
> question probably do we really have to have three separate interfaces
> DateField, TimeField, DateTimeField and plus the "Rule" to make the
> whole system work, other than the benefits of (1) "some type safety"
> that Richard mentioned in the separate email and (2) the clear
> separation of low and lower access interface. For example, with a
> common base Interface DateTimeField<T>, as I suggested in early
> email,

DateTimeField cannot be generified by T. That approach would cause
there to be two definitions of MONTH_OF_YEAR, one for LocalDate and
one for LocalDateTime.

As such, a combined API looks like this:

public interface DateTimeField  {
      String getName();
      DateTimeValueRange getValueRange();
      PeriodUnit getBaseUnit();
      PeriodUnit getRangeUnit();
      long getValueFrom(CalendricalObject calendrical);

      DateTimeValueRange range(LocalDate date);
      DateTimeValueRange range(LocalTime time);
      DateTimeValueRange range(LocalDateTime dateTime);
      long get(LocalDate date);
      long get(LocalTime time);
      long get(LocalDateTime dateTime);
      LocalDate set(LocalDate date, long newValue);
      LocalTime set(LocalTime time, long newValue);
      LocalDateTime set(LocalDateTime dateTime, long newValue);
      LocalDate roll(LocalDate date, long roll);
      LocalTime roll(LocalTime time, long roll);
      LocalDateTime roll(LocalDateTime dateTime, long roll);
      boolean resolve(DateTimeBuilder builder, long value);
}

As you can see, the API is not as pretty.

The alternative would be instanceof checks within each method using
local generics:
      <T> T set(T dateOrTime, long newValue) {
        if (dateOrTime instanceof LocalDate) {
          return (T) ((LocalDate) dateOrTime).with...
        }
        if (dateOrTime instanceof LocalDateTime) {
          return (T) ((LocalDateTime) dateOrTime).with...
        }
        throw invalid
     }

Lots more ugly code for implementors. Probably worse performance.

> On the other hand, doesn't the current design introduce
> in a limit on the "extensibility" (which is all this
> package about) of having a customized date/time field/type?
> for example, someone might want to have a customized date/
> time field XYZField for a customized date/time type
> XYZDateTime, in which it might not fit into any of LocalDate,
> LocalTime or LocalDateTime? Something otherwise might be
> possible if the DateTimeField is a genetic common base
> interface, for example,
>
> public enum/class XYZField implements DateTimeField<XYZDateTime>  {...}

As I indicated in the document, there are many, many, many ways in
which a date/time API can be extended. We can easily come up with
them. My goal has been to restrict the degrees of freedom to something
manageable. Limiting by LD/LT/LDT seems like a reasonable restriction.
Why do those wanting something else (which is necessarily very weird)
need to be integrated with 310 at all?

> I understand this a a design choice as you suggested in
> your writeup for the "pirate" branch, and unfortunately
> it appears I'm on the opposite side of the choices that
> made into existing design. But it is really attractive
> to remove 3 or 4 more abstractions out of a design that
> already appears to have lots of abstractions...

If people think that the interface I outlined above is simper, then it
is an easy change. I'm unconvinced but open to discuss.

> Btw, why does the "pirate" branch only have the calendrical
> and zone subpackage? Just wonder if I'm doing something
> wrong in my git.

The code has been modularized. src is the core, src-standard is the
standard module.

Stephen