From users-return-2822-apmail-groovy-users-archive=groovy.apache.org@groovy.apache.org Tue Jun 27 14:31:34 2017 Return-Path: X-Original-To: apmail-groovy-users-archive@minotaur.apache.org Delivered-To: apmail-groovy-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id D74A31AC36 for ; Tue, 27 Jun 2017 14:31:34 +0000 (UTC) Received: (qmail 63833 invoked by uid 500); 27 Jun 2017 14:31:34 -0000 Delivered-To: apmail-groovy-users-archive@groovy.apache.org Received: (qmail 63800 invoked by uid 500); 27 Jun 2017 14:31:34 -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 63789 invoked by uid 99); 27 Jun 2017 14:31:34 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 27 Jun 2017 14:31:34 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 26C601A0846 for ; Tue, 27 Jun 2017 14:31:34 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.38 X-Spam-Level: *** X-Spam-Status: No, score=3.38 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_REPLY=1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id GyA4TLSRnI1m for ; Tue, 27 Jun 2017 14:31:31 +0000 (UTC) Received: from mail-yw0-f171.google.com (mail-yw0-f171.google.com [209.85.161.171]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 6C2EB5F60D for ; Tue, 27 Jun 2017 14:31:30 +0000 (UTC) Received: by mail-yw0-f171.google.com with SMTP id l21so4076189ywb.1 for ; Tue, 27 Jun 2017 07:31:30 -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=ImtebVz16l6DlAbpAaOpRYiJx7Iy1WezqF9pni+9nx8=; b=ZKt1K716cQl4pVwR8okHWcwUmvWLWaORS5tPIYrrmzXRtfa/0v6NRrFOL+pVjU97M1 2Cz82Yg+2sUwvC+AnaH1mVmMRYSZZ67ziu2CnTySYD2vZl7eR/4B86Nm2hRKqPPhQmHy Td4w+do0roAFNPkzAVmTXRFI3L26vIzK8n1EBYRIuLtaMU3dVprwc+2pVOodnD0C5NBV hpulkQ2g24NiYzd1RitpYOjNvqLGx1SreKQCcRZ0UqfOTUamKIcBWTEbQocT7WDNFvuO uU4X7PTbXkkWEddcF78mUomisTHDiWw7JxaJlawil7Dda/s0DowinFoeBkUg6ZX+y85d wrZg== 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=ImtebVz16l6DlAbpAaOpRYiJx7Iy1WezqF9pni+9nx8=; b=h9vZgMZhNQPNR2gbZOjAEsw85MeWbob7XiLik/mCA/mNw39fR3/lc90o11JPu1MIW/ QZSNYe0WyN2O1OiG0xev89PIboiDfKBZla2TD3YSUoDTeBu0LzfpXsZFLnXDAxLr0jej kCXxiw/E6nuD3dv1ffX8EZ+izk9eF+fE6La7TQWz9L1/G2xgrgs2tHuQX4d4+M9xbFDK TtuR5GacW6hgyvncn9RSGWmKBSa0LHQ3/owfpb9Ch8gQKVX6ZGtoex2dLngGP4rBSa6W ZWkUu5YcetmWnXWcj0Mb2x1mxDEV6OPny5MDjV0kvLmJISx/5/GmsMfCwLd+/c40Rdl/ Ziyw== X-Gm-Message-State: AKS2vOwHVZdr1FUAvp+zTC6YhTi/J8zsW8qr95po0zP6Mt66Vegb8GzG y6v+XtYFX7bOe3vuPRfNRrNZ374pQt1C X-Received: by 10.129.118.8 with SMTP id r8mr4048248ywc.7.1498573888930; Tue, 27 Jun 2017 07:31:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.112.137 with HTTP; Tue, 27 Jun 2017 07:31:28 -0700 (PDT) In-Reply-To: References: <1496920151.10302.14.camel@winder.org.uk> <1496921651.10302.16.camel@winder.org.uk> From: Guillaume Laforge Date: Tue, 27 Jun 2017 16:31:28 +0200 Message-ID: Subject: Re: Java 8 Date/Time API Extension Methods To: users@groovy.apache.org Content-Type: multipart/alternative; boundary="f403045f039a51e1950552f1ecc7" --f403045f039a51e1950552f1ecc7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sure, when you're ready / happy, feel free to start a thread on the dev list. On Tue, Jun 27, 2017 at 4:48 AM, Joe Wolf wrote: > 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 >> kind 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 peopl= e >>> 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% co= ntent >>>> 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. Alt= hough >>>> 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 goodt= imes >>>> 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 th= e >>>> 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 wha= t >>>>> 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 >>>>>> 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 >>>>>> 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 w= rote: >>>>>>>>> >> > > 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 everythin= g >>>>>>>>> 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. >>>>>>>>> > =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_winde= r >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> 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+ >> >> > > --=20 Guillaume Laforge Apache Groovy committer & PMC Vice-President Developer Advocate @ Google Cloud Platform Blog: http://glaforge.appspot.com/ Social: @glaforge / Google+ --f403045f039a51e1950552f1ecc7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sure, when you're ready / happy, feel free to start a = thread on the dev list.

On Tue, Jun 27, 2017 at 4:48 AM, Joe Wolf <= ;joewolf@gmail.com> wrote:
I&#= 39;m all on board for integrating into Groovy, and I'm letting that dri= ve design decisions as I finish up the changes. I appreciate the feedback o= n the API--I will definitely take it all under consideration. Perhaps we sh= ould move integration-related discussions over to the dev mailing list.

-Joe

On Mon, Jun 26, 2017 at 7:51 AM, G= uillaume 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= , keeping upto / downto in addition would be kind to people used to using t= hem.

Anyhow, very nice work!
I still bel= ieve we need to integrate it to Groovy core :-)

Guillaum= e

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

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

Ch= eers,
Ahm



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

I'm mul= ling the addition of static parse() methods akin to the Groovy JDK's=C2= =A0Date.parse(String format, String input) method, but am wrestling with ar= gument ordering. Date.parse accepts the format as the first argument; the n= ew 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 leani= ng 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 goodt= imes adds next() and previous() methods, the range operator can be used to = replicate their function

earlier.upto(later) {= } --> (earlier..later).each {}
later.downto(earlier) {}=C2=A0-= -> (later..earlier).each {}

I'm also questi= oning the existence of the getAt(int calendarField) methods. On the downsid= e, 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. ja= va.util.Calendar comes for free.

-Joe

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

Guillaum= e

<= div class=3D"m_-2672740322304806238m_8343821982200720421m_-2305084450650261= 447m_2861132355759576345h5">
On Fri, Jun 9, 2= 017 at 5:07 AM, Joe Wolf <joewolf@gmail.com> wrote:
+1 for me. I think it's a go= od idea.

Not everything in the current API may be worthw= hile to have as part of Groovy proper, though. For example, the bridging me= thods from the java.time classes back to Date and Calendar could be unneces= sarily promoting the latter's usage.

By the wa= y, I'm currently working to add extension methods to the java.time type= s involving ZoneId and ZoneOffset. I hope to have that completed in a coupl= e of weeks or so.

-Joe

On Thu, Jun 8, 2017 at 7:52 PM, Mario Garcia <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 <dinko.srkoc@gmail.com<= /a>> wrote:
On 8 June 201= 7 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-Presid= ent
Developer Advocate @ Google Cloud Platform





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





--
=
--f403045f039a51e1950552f1ecc7--