Hi Jim, @static parse(): I am with you on keeping the Java 8 API ordering, but I would not jettison the upto and downto methods, as to not confuse people switching from Java 8 to Groovy.
Cheers, Ahm Joe Wolf <[email protected]> schrieb am So., 25. Juni 2017, 23:32: > Goodtimes 1.1 is out with new extension methods on the zone-based types, > effectively covering the entire java.time.* package (except for Clock, > which I haven't found need to extend). I'd say I'm about 98% content with > the API. > > I'm mulling the addition of static parse() methods akin to the Groovy > JDK's Date.parse(String format, String input) method, but am wrestling with > argument ordering. Date.parse accepts the format as the first argument; the > new java.time API parse methods accept the date/time string first. Although > I've aimed to be consistent with the Groovy JDK thus far, I'm leaning > towards following the Java 8 API ordering in this case. > > On the other side of the coin, I am contemplating jettisoning the upto and > downto methods. Since the java.time types are Comparable and goodtimes adds > next() and previous() methods, the range operator can be used to replicate > their function > > earlier.upto(later) {} --> (earlier..later).each {} > later.downto(earlier) {} --> (later..earlier).each {} > > I'm also questioning the existence of the getAt(int calendarField) > methods. On the downside, it's munging the older java.util API with the > new; on the upside, I don't have to explicitly import > java.time.temporal.ChronoField. java.util.Calendar comes for free. > > -Joe > > On Fri, Jun 9, 2017 at 8:51 AM, Guillaume Laforge <[email protected]> > wrote: > >> Keep us updated on the new extensions, and once you're happy with what >> you have come up with, I believe it'd really be awesome to have it >> integrated. >> >> Guillaume >> >> >> On Fri, Jun 9, 2017 at 5:07 AM, Joe Wolf <[email protected]> wrote: >> >>> +1 for me. I think it's a good idea. >>> >>> Not everything in the current API may be worthwhile to have as part of >>> Groovy proper, though. For example, the bridging methods from the java.time >>> classes back to Date and Calendar could be unnecessarily promoting the >>> latter's usage. >>> >>> By the way, I'm currently working to add extension methods to the >>> java.time types involving ZoneId and ZoneOffset. I hope to have that >>> completed in a couple of weeks or so. >>> >>> -Joe >>> >>> On Thu, Jun 8, 2017 at 7:52 PM, Mario Garcia <[email protected]> >>> wrote: >>> >>>> +1 >>>> >>>> I think Many Groovy applications could benefit from having this in >>>> Groovy. >>>> >>>> 2017-06-09 1:02 GMT+02:00 Paul King <[email protected]>: >>>> >>>>> +1 from me, but I'd be keen to hear Joe's thoughts? >>>>> >>>>> Cheers, Paul. >>>>> >>>>> >>>>> On Thu, Jun 8, 2017 at 10:37 PM, Dinko Srkoč <[email protected]> >>>>> wrote: >>>>> >>>>>> On 8 June 2017 at 13:34, Russel Winder <[email protected]> wrote: >>>>>> > On Thu, 2017-06-08 at 13:18 +0200, Dinko Srkoč wrote: >>>>>> >> On 8 June 2017 at 13:09, Russel Winder <[email protected]> >>>>>> wrote: >>>>>> >> > On Wed, 2017-06-07 at 14:38 +0000, Søren Berg Glasius wrote: >>>>>> >> > > I think it makes perfect sense that you can do the same >>>>>> >> > > calculations >>>>>> >> > > with >>>>>> >> > > java.time.* as you can with java.util.Date >>>>>> >> > > >>>>>> >> > >>>>>> >> > Shouldn't it be fair to assume that all new code eschews >>>>>> >> > java.util.Date >>>>>> >> > and all the Calendar stuff, and uses java.time for everything >>>>>> time >>>>>> >> > and >>>>>> >> > date related? >>>>>> >> >>>>>> >> I think this falls into a category of "hope" or "wish", rather than >>>>>> >> "assumption" :-) >>>>>> > >>>>>> > True, but I was hoping that unlike a large percentage of Java >>>>>> > developers who are hugely reluctant to learn anything new they do >>>>>> not >>>>>> > already know (*), Groovy developers were very much into using the >>>>>> best >>>>>> > new idiomatic ways of doing things (well except for stuff that is >>>>>> just >>>>>> > fashionably trendy for a few days) and keeping their codebases up to >>>>>> > date with up-to-date Groovy. >>>>>> > >>>>>> > Please do not shatter my illusions. >>>>>> >>>>>> haha! >>>>>> >>>>>> Okay, I could convince myself that it is indeed so with Groovy >>>>>> developers. :-) >>>>>> >>>>>> > >>>>>> > >>>>>> > >>>>>> > (*) And are thus part of the legacy problem. >>>>>> > >>>>>> > -- >>>>>> > Russel. >>>>>> > >>>>>> ============================================================================= >>>>>> > Dr Russel Winder t: +44 20 7585 2200 voip: >>>>>> sip:[email protected] >>>>>> > 41 Buckmaster Road m: +44 7770 465 077 xmpp: >>>>>> [email protected] >>>>>> > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder >>>>>> >>>>> >>>>> >>>> >>> >> >> >> -- >> Guillaume Laforge >> Apache Groovy committer & PMC Vice-President >> Developer Advocate @ Google Cloud Platform >> >> Blog: http://glaforge.appspot.com/ >> Social: @glaforge <http://twitter.com/glaforge> / Google+ >> <https://plus.google.com/u/0/114130972232398734985/posts> >> > >
