Re: [threeten-develop] Threeten method consistency

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

On 1 May 2012 18:26, Roger Riggs <Rog...@or...> wrote:
> With respect to Era,  ISO could be considered to have single Era so that it
> fits into the more
> general model.   A singularity that ISO programmers would ignore.

Possible, but there is still a method name problem. getYear() for
LocalDate needs to be just the year, whereas for ChronoDate it is an
explicitly named getProlepticYear() - deliberately designed to force
users into using getYearOfEra() - and again deliberately designed to
encourage the thought process as to why things are the way they are.

> But if you don't subscribe to that, an alternative would be remove the Era
> from the calendar neutral dates and expose subtypes of dates that
> have Eras.    From my perspective, it would a cleaner API to expose
> specific subtypes of dates for the calendars that have unique features.
> Similar to the extended functionality of LocalDate, etc.  The other Date
> types could expose their unique features without being forced to
> restrict their functionality.  Developers are interested in the behavior
> of the Date classes and the indirection to a Chrono/Chronology makes that
> less visible.  It would be model more consistent across the ISO and other
> calendars.

Exposing the various classes like CopticDate or MinguoDate is an easy
API change. However it increases the size of the publc API and would
require more public methods (factory methods on each date subclass,
not needed if they are hidden). When you suggested providing room for
the API to grow, this is a perfect example.

I do think that the CopticDate  classes etc should be package scoped
top level however, to avoid serialization changes were they to become
publc in the future.

> The date classes exist already and if public would be a more natural API to
> expose the unique features of dates.

If there are any unique features. Doing this would put pressure on to
have a Month enum for every calendar system, growing the API again...

Stephen