Re: [threeten-develop] Multi-Calendar API refinement
Status: Alpha
Brought to you by:
scolebourne
From: Roger R. <Rog...@or...> - 2012-10-30 16:55:52
|
Hi, I was hoping that extract going away was still a possible future. Your idea to map them to numbers and back through the get() interface had some appeal. It would work well enough with Chronology.from(dt) and ZoneId.from(dt). Unfortunately, Era as an interface can't have a static method (yet). Roger On 10/30/2012 12:07 PM, Stephen Colebourne wrote: > On 30 October 2012 15:58, Roger Riggs<Rog...@or...> wrote: >>> I think that the Chronology.now() methods might be better named >>> dateNow(). This is because they are not creating a current chronology, >>> but a current date. It also allows use to add dateTimeXxx() methods if >>> desired (either JDK 8 or beyond). >> yes, the naming needs to be improved. I'm also partial to using "today" >> when it >> comes to dates without a time. > When we had methods on Clock, they were called today(), yesterday() > and tomorrow(). In the end, I went with now() everywhere simply to > make it consistent (and in general 310 makes use of common words in > the API to keep it manageable). now() is also shorter. > >>> Did I miss getEra() on ChronoDate last time? It is a concern, as it is >>> exposed on LocalDate et al. I understand why ChronoDate users want it >>> though. I guess its a compromise I have to make to move us forwards. >> Developers are not accustomed to using Eras in most calendars but the API >> makes them hard to ignore. Only for Japanese, is it really a necessary. >> >> The alternative to the getEra method is: >> dt.getChronology().eraOf(dt.get(LocalDateTimeField.ERA)); >> >> If it is expected that Era will only be used with the factories then >> getEra() can be omitted. > I think people will not generally query or manipulate the era, so its > not an essential getter. (The era will just be something updated by > the query methods and output by the formatter, which don't need a > getEra()). > > We need to fixup what the extract() method semantics are. > Unfortunately generics don't help, but an acceptable alternative to > getEra() might be extract(Era.class). > > Stephen > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_sfd2d_oct > _______________________________________________ > threeten-develop mailing list > thr...@li... > https://lists.sourceforge.net/lists/listinfo/threeten-develop -- Thanks, Roger Oracle Java Platform Group Green Oracle <http://www.oracle.com/commitment> Oracle is committed to developing practices and products that help protect the environment |