Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id D8AC1200CC5 for ; Tue, 27 Jun 2017 04:48:41 +0200 (CEST) Received: by cust-asf.ponee.io (Postfix) id D6336160BDE; Tue, 27 Jun 2017 02:48:41 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id A72C5160BDA for ; Tue, 27 Jun 2017 04:48:40 +0200 (CEST) Received: (qmail 16039 invoked by uid 500); 27 Jun 2017 02:48:39 -0000 Mailing-List: contact users-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.apache.org Delivered-To: mailing list users@groovy.apache.org Received: (qmail 16029 invoked by uid 99); 27 Jun 2017 02:48:39 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Jun 2017 02:48:39 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 42E75C028B for ; Tue, 27 Jun 2017 02:48:39 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id DXVHlxjooj3k for ; Tue, 27 Jun 2017 02:48:36 +0000 (UTC) Received: from mail-pf0-f181.google.com (mail-pf0-f181.google.com [209.85.192.181]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 663495FBBF for ; Tue, 27 Jun 2017 02:48:36 +0000 (UTC) Received: by mail-pf0-f181.google.com with SMTP id e7so9229537pfk.0 for ; Mon, 26 Jun 2017 19:48:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=M9atuyuELEJBWqHECrDuXDBm4bigjqY+zF2ZmMnAxxM=; b=QUog+b9UutcyHNHKuPMv6nZvvyQzFtqI24A2dux5rO/Iy6fVArg7Q+YvhrNws0tqM2 ZJ754i1gb2yHc9c+0k//QaifUoHxkw03gNXgaOzDoDqTy9cqLGpZqLW5RFHG5vz39L9A WfwvhL1tm6zYERusQXkxsKcMUlHUkBkSHruoE6zLXFCaF6DUXcs/DagS1ZmoW7Izra8b Eq8vCTfR/ZY1wJnpPV5bE33ryo/awUr72uLXZ5aEsaZyBEm1Ge31MJIXeZYkputX4CrY x2rNxmyQS59WMhunwc1v+Xlj9tXD6QKsGd9qkPmpPlusX2VVBXTeTw0noxDxs8Ub1lal dOBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=M9atuyuELEJBWqHECrDuXDBm4bigjqY+zF2ZmMnAxxM=; b=Hd9q3sssgn5ZJ+plT9V+c7nj3JpW7CFHMO8r+4w9+hmIAOHt1aZrUs60hpkkon7rWM PrXlOZl/xzeuNIdMVx9rh/gjJpu0E+ikFq8/CHqT2BlUKYcdoH4PcCogFYxexaCvkfO8 NsymHgZrnDtgrwVxNUyumPZJ+4XYarEYdjT2dxgqG9/WBkv5c7EkHgt2f8gg5v1jyhiD kk55nvs7d/dwjKVrdoA+pGEBH2IVvXAmRgoS33FjU/ob/dnNWXffnp5ZWbpPFhI8VMYW n3ZgpYSoyTN+9c6Bar8cLB36D9ssXSja9bTzk7cGCA60ENl74kZZT6iNp/qowwx5M460 g/ag== X-Gm-Message-State: AKS2vOycl2Jb8vwNw8/cFAtSJGF1bOos1Os+YN5WZjptHVVHuOSh97Ty EeCS4ZcgFWBU++X4vMYQTdSIMJpk6g== X-Received: by 10.84.237.15 with SMTP id s15mr3437993plk.100.1498531715116; Mon, 26 Jun 2017 19:48:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.186.204 with HTTP; Mon, 26 Jun 2017 19:48:34 -0700 (PDT) In-Reply-To: References: <1496920151.10302.14.camel@winder.org.uk> <1496921651.10302.16.camel@winder.org.uk> From: Joe Wolf Date: Mon, 26 Jun 2017 22:48:34 -0400 Message-ID: Subject: Re: Java 8 Date/Time API Extension Methods To: users@groovy.apache.org Content-Type: multipart/alternative; boundary="94eb2c1ceb7e90748c0552e81a4d" archived-at: Tue, 27 Jun 2017 02:48:42 -0000 --94eb2c1ceb7e90748c0552e81a4d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm all on board for integrating into Groovy, and I'm letting that drive design decisions as I finish up the changes. I appreciate the feedback on the API--I will definitely take it all under consideration. Perhaps we should move integration-related discussions over to the dev mailing list. -Joe On Mon, Jun 26, 2017 at 7:51 AM, Guillaume Laforge wrote: > I also think it's sane to keep the Java 8 ordering in this case. > > Even if we can use ranges, keeping upto / downto in addition would be kin= d > to people used to using them. > > Anyhow, very nice work! > I still believe we need to integrate it to Groovy core :-) > > Guillaume > > On Mon, Jun 26, 2017 at 8:10 AM, Ahm Avoby > wrote: > >> 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 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 wi= th >>> 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. Alth= ough >>> 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 goodti= mes >>> 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 >>> 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 wrote: >>>> >>>>> +1 for me. I think it's a good idea. >>>>> >>>>> Not everything in the current API may be worthwhile to have as part o= f >>>>> Groovy proper, though. For example, the bridging methods from the jav= a.time >>>>> classes back to Date and Calendar could be unnecessarily promoting th= e >>>>> 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 >>>>> wrote: >>>>> >>>>>> +1 >>>>>> >>>>>> I think Many Groovy applications could benefit from having this in >>>>>> Groovy. >>>>>> >>>>>> 2017-06-09 1:02 GMT+02:00 Paul King : >>>>>> >>>>>>> +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=C4=8D >>>>>>> wrote: >>>>>>> >>>>>>>> On 8 June 2017 at 13:34, Russel Winder >>>>>>>> wrote: >>>>>>>> > On Thu, 2017-06-08 at 13:18 +0200, Dinko Srko=C4=8D wrote: >>>>>>>> >> On 8 June 2017 at 13:09, Russel Winder >>>>>>>> wrote: >>>>>>>> >> > On Wed, 2017-06-07 at 14:38 +0000, S=C3=B8ren Berg Glasius wr= ote: >>>>>>>> >> > > 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 d= o >>>>>>>> not >>>>>>>> > already know (*), Groovy developers were very much into using th= e >>>>>>>> best >>>>>>>> > new idiomatic ways of doing things (well except for stuff that i= s >>>>>>>> just >>>>>>>> > fashionably trendy for a few days) and keeping their codebases u= p >>>>>>>> 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. >>>>>>>> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>>>>>> > Dr Russel Winder t: +44 20 7585 2200 voip: >>>>>>>> sip:russel.winder@ekiga.net >>>>>>>> > 41 Buckmaster Road m: +44 7770 465 077 xmpp: >>>>>>>> russel@winder.org.uk >>>>>>>> > 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 / Google+ >>>> >>>> >>> >>> > > > -- > Guillaume Laforge > Apache Groovy committer & PMC Vice-President > Developer Advocate @ Google Cloud Platform > > Blog: http://glaforge.appspot.com/ > Social: @glaforge / Google+ > > --94eb2c1ceb7e90748c0552e81a4d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm all on board for integrating into Groovy, and I= 9;m letting that drive design decisions as I finish up the changes. I appre= ciate the feedback on the API--I will definitely take it all under consider= ation. Perhaps we should move integration-related discussions over to the d= ev mailing list.

-Joe

On Mon, Jun 26, 2017 at 7:51 AM, Guillau= me Laforge <glaforge@gmail.com> wrote:
I also think it's sane to keep the Java = 8 ordering in this case.

Even if we can use ranges, keep= ing upto / downto in addition would be kind to people used to using them.

Anyhow, very nice work!
I still believe w= e need to integrate it to Groovy core :-)

Guillaume
<= div class=3D"HOEnZb">

On Mon, Jun 26, 2017 at 8:10 AM, Ahm Avoby <a= liencheckout@gmail.com> wrote:
Hi Jim,

@static parse(): I am with you on keeping the=C2=A0Java = 8 API ordering, but I would not=C2=A0jettison the upto and downto methods, = as to not confuse people switching from Java 8 to Groovy.

Cheers,
Ahm


=
Joe Wolf <joewolf@gmail.com> schrieb = am So., 25. Juni 2017, 23:32:
Goodtimes 1.1 is out with new extension methods on the zone-bas= ed types, effectively covering the entire java.time.* package (except for C= lock, which I haven't found need to extend). I'd say I'm about = 98% content with the API.

I'm mulling the addition o= f static parse() methods akin to the Groovy JDK's=C2=A0Date.parse(Strin= g format, String input) method, but am wrestling with argument ordering. Da= te.parse accepts the format as the first argument; the new java.time API pa= rse methods accept the date/time string first. Although I've aimed to b= e consistent with the Groovy JDK thus far, I'm leaning towards followin= g the Java 8 API ordering in this case.

On the oth= er side of the coin, I am contemplating jettisoning the upto and downto met= hods. Since the java.time types are Comparable and goodtimes adds next() an= d previous() methods, the range operator can be used to replicate their fun= ction

earlier.upto(later) {} --> (earlier..= later).each {}
later.downto(earlier) {}=C2=A0--> (later..earli= er).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 e= xplicitly import java.time.temporal.ChronoField. java.util.Calendar co= mes for free.

-Joe

On Fri, Jun 9, 2017 at 8:51 AM, G= uillaume Laforge <glaforge@gmail.com> wrote:
Keep us updated on the new extensions,= and once you're happy with what you have come up with, I believe it= 9;d really be awesome to have it integrated.

Guillaume

=

On Fr= i, Jun 9, 2017 at 5:07 AM, Joe Wolf <joewolf@gmail.com> wrot= e:
+1 for me. I think it= 's a good idea.

Not everything in the current API ma= y 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 jav= a.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 Gar= cia <mario.ggar@gmail.com> wrote:
+1=C2=A0

I think Many Groovy= applications could benefit from having this in Groovy.

2017-06-09 1:02 GMT+02:00 Paul King <paulk@asert.com.au>:
+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=C4=8D <<= a href=3D"mailto:dinko.srkoc@gmail.com" target=3D"_blank">dinko.srkoc@gmail= .com> wrote:
On 8 Jun= e 2017 at 13:34, Russel Winder <russel@winder.org.uk> wrote:
> On Thu, 2017-06-08 at 13:18 +0200, Dinko Srko=C4=8D wrote:
>> On 8 June 2017 at 13:09, Russel Winder <russel@winder.org.uk> wrote:
>> > On Wed, 2017-06-07 at 14:38 +0000, S=C3=B8ren Berg Glasius wr= ote:
>> > > I think it makes perfect sense that you can do the same<= br> >> > > calculations
>> > > with
>> > > java.time.* as you can with java.util.Date
>> > >
>> >
>> > Shouldn't it be fair to assume that all new code eschews<= br> >> > 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 "wi= sh", 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<= br> > 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.
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
> Dr Russel Winder=C2=A0 =C2=A0 =C2=A0 t: +44 20 7585 2200= =C2=A0 =C2=A0voip: sip:russel.winder@ekiga.net
> 41 Buckmaster Road=C2=A0 =C2=A0 m: +44 7770 465 077=C2=A0 = =C2=A0xmpp: russe= l@winder.org.uk
> London SW11 1EN, UK=C2=A0 =C2=A0w: www.russel.org.uk=C2=A0 skype: r= ussel_winder






<= /div>--
Guillaume = Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform





--

--94eb2c1ceb7e90748c0552e81a4d--