Re: [threeten-develop] Generic API

[S. M. <s.m...@de...>]

The more I study ThreeTen, the more I appreciate its design. I am no longer starting to like it, I am starting to love it :-).

Making ChronoDate implement DateTimeObject was a good step forward. ChronoDate now almost provides what I need (at least for now). That said, I still think you should try to merge ChronoDate and LocalDate. Currently, it is not possible to combine a ChronoDate with a time. One could implement a ChronoDateTime in the same way as LocalDateTime, but this would be awkward. You would have two almost identical implementations. ChronoDate and LocalDate already share many methods.

Instead, I think that each ChronoDate is also a local date and therefore should be a subtype of LocalDate. LocalDate would become an abstract class or interface, and the ISO-specific methods on LocalDate would be pushed down to ISODate. Wouldn't that be at least worth a try? You already have so many branches, one more doesn't harm ... :-)  Of course, this would entail many changes in OffsetDateTime and ZoneDateTime; many methods on these classes are just delegates and could be removed. This would simplify the API, but also remove some convenience.

Here's some more feedback:

DateTimeObject:
    - should have methods roundFloor(DateTimeField)
      and roundCeiling(DateTimeField)

PeriodUnit:
    - Method add(R calendrical, long periodToAdd):
      The Javadoc says: "Rolls the value of the PeriodUnit ..."
      This is confusing, because it suggests a change to the PeriodUnit.
      Instead, the provided 'calendrical' is manipulated. It could be
      reworded "Adds this period to the given calendrical object ..."
      
      The parameter "periodToAdd" should be "amount" or "amountToAdd".
      The method name "add" could be renamed "addTo" for clarity.

Chrono:
    - There should be a method to query the DateTimeFields that are defined.
      Chrono.getFields() : DateTimeField[]
    
    - There should be a method getField(String name) : DateTimeField.
      This would make it possible to query corresponding fields from
      different implementations/calendars. For example, an ISOWeekChrono
      could have its own ISOWeekDateTimeField enum with YEAR and WEEK,
      but without MONTH. The YEAR field would be accessible via the
      standardized name "Year".
      
      Implementations using an Enum for their fields could implement
      this as follows:
          Example: return LocalDateTimeField.valueOf(name.toUpperCase())

DateTimeField:
    - Shouldn't getBaseUnit() be just getUnit()? This is the unit
      in which the field is measured. There is no secondary unit.

LocalDateTimeUnit
    - There should be a distiction between "primary" fields like
      year/month/day and "auxiliary/derived/computed" fields
      like day-of-week/week-of-year.
      
      Imagine you want to implement a universal date picker that
      can be used with any calendar. It would have a drop-down control
      for each field, but you wouldn't want a drop-down field for
      "week-of-year", at least not by default.
      
      This could be implemented as DateTimeField.isPrimaryField() : boolean

    - Minor detail: isDurationEstimated() returns true for DAYS;
      then for HALF_DAYS it should probably also return true

    - FOREVER is not a good name because it is an adverb;
      also, it sounds more like an open-ended period than a unit.
      What about ALLTIME?

    - MILLENIA and "Millenia" should be spelled with two "n"
      Likewise, "millenium" in the Javadoc should have two "n".

Stefan

On 22/6/2012 14:59:15, Stephen Colebourne wrote:
> On master, ChronoDate now extends DateTimeObject.
> 
> DateTimeObject represents any type of date/time where the date/time
> information forms a complete set such that it can be added to. For
> example, a LocalDate is complete (from day to forever), as is
> YearMonth (from month to forever), as is LocalTime (from nano to day).
> 
> MonthDay is not complete, as you cannot add to the day-of-month field
> without knowing the year. As such, MonthDay is merely a
> DateTimeCalendrical - effectively a map of field to value.
> 
> Since the enums all form a complete set of values (there is never a
> missing day-of-week, or month) they are DateTimeObject
> implementations.
> 
> You should be able to implement JulianDayDate, or YearWeekDate
> reasonably easily based on DateTimeObject at this point. Im fact, we
> should probably have a class like this in the repo for confirming the
> validity of the API.
> 
> Stephen
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. 
> Discussions  will include endpoint security, mobile security and the 
> latest in malware  threats. 
> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ 
> _______________________________________________ threeten-develop mailing 
> list thr...@li...
> https://lists.sourceforge.net/lists/listinfo/threeten-develop