Re: [threeten-develop] Generic API
Status: Alpha
Brought to you by:
scolebourne
From: Stephen C. <sco...@jo...> - 2012-06-22 14:59:42
|
On 21 June 2012 23:56, Stefan Mücke <s.m...@de...> wrote: >> What I struggle with is the need to extend ChronoDate. There are now >> lots of other interfaces to extend from depending on what date/time >> info your class exposes. Why can we not leave ChronoDate to be for >> those calendar systems that are based on YMD? > > In that case (and otherwise too), shouldn't ChronoDate implement DateTimeObject? Currently it only implements CalendricalObject. DateTimeObject would become the primary type used in client code and should then be renamed DateTime. One problem I currently see with this is that the enums AmPmOfDay, DayOfWeek, MonthOfYear, QuarterOfYear all implement DateTimeObject but do not refer to any specific point in time. Just an idea: Maybe introduce DateTimeEnum as a common interface for these enums. 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 |