From users-return-2819-apmail-groovy-users-archive=groovy.apache.org@groovy.apache.org Mon Jun 26 06:49:03 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 CDB3319766 for ; Mon, 26 Jun 2017 06:49:03 +0000 (UTC) Received: (qmail 34481 invoked by uid 500); 26 Jun 2017 06:49:03 -0000 Delivered-To: apmail-groovy-users-archive@groovy.apache.org Received: (qmail 34440 invoked by uid 500); 26 Jun 2017 06:49:03 -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 34430 invoked by uid 99); 26 Jun 2017 06:49:03 -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; Mon, 26 Jun 2017 06:49:03 +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 11A3D1A7A8C for ; Mon, 26 Jun 2017 06:49:03 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.9 X-Spam-Level: X-Spam-Status: No, score=-0.9 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id 8Cy8NN8p9EMG for ; Mon, 26 Jun 2017 06:49:01 +0000 (UTC) Received: from mail-wr0-f179.google.com (mail-wr0-f179.google.com [209.85.128.179]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 6AC615F6C0 for ; Mon, 26 Jun 2017 06:49:00 +0000 (UTC) Received: by mail-wr0-f179.google.com with SMTP id 77so138474764wrb.1 for ; Sun, 25 Jun 2017 23:49:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :references:in-reply-to:to; bh=7os3+XVuLeAsbcmlglNXZ+9jmK4f69BZ5d/8YiktbIM=; b=OgMK6B2Q/k19UctmzXST27vtimQYl4o+Qr3+rMhfj8KkqIDVdKHRtKkFEIemoYKpud CGQxcaBzFTuY3JhmhR9AzQglAT1dNExnt48/IIxoCRtBvvrvMkTN0nYWofdqZDiuHz/0 Ef7vXTJPXkA6hZasn8iM5GCYevW0S1VxLJM0qhlOg3p/wsHZcDQu1/cV8bPuxjexqQm/ 0q5ZVLXUFgCdeJjY7t+pU+0ibw0Jlt1PIFyAzhgQtwvFCo0nAwL1YTk28MB+nw4jzv08 qrNYP9lhOmyFRxMWaCxTzJZ/3o2GZ0zIWiagyVOPAF2s2ii5fPs2a9IA8R2FRWlVDXZN 5p/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:references:in-reply-to:to; bh=7os3+XVuLeAsbcmlglNXZ+9jmK4f69BZ5d/8YiktbIM=; b=hMnZnB6AmY2WgwmEkZ8pdlFOMNPqPp8I68nOyd/pc/vlyN74sSWbXS5bjFRsovCzgE 3FqSpr72Ijwjk+Sw/6JRFctCpPUEhG+3Nbz97XQfHDs+wnkQjU2DqDqwImCi1YuXHcBO sXaX416DhXF6BGWYD6sIK2e58Xm8VhX4V/fJoehxGz4phGFz9cKANsgACBxyCtpC+3uf qfnaC1ryih++T5KjdUkKqhZFNOjojdZoO7l9x2JQgk2mYSgCSrXTY4CmCP+pLFW5JIZD /HqKp6486xlxuQecNOebvANC888CltJJ4cftuID554IzEXfwBnvd/njgDUcaKtgVeIPn ECmA== X-Gm-Message-State: AKS2vOyLg6ECneNENvu1UYsHLtiP4RZY2rKpX3JNK0h19dO/xfqL2D1I mfom7+Hksn/kgnH0e+g= X-Received: by 10.223.133.239 with SMTP id 44mr3176686wru.177.1498459733478; Sun, 25 Jun 2017 23:48:53 -0700 (PDT) Received: from [192.168.1.9] (ARennes-552-1-40-39.w92-135.abo.wanadoo.fr. [92.135.207.39]) by smtp.gmail.com with ESMTPSA id 201sm17602791wmy.15.2017.06.25.23.48.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Jun 2017 23:48:52 -0700 (PDT) From: jim northrop Content-Type: multipart/alternative; boundary=Apple-Mail-F3F83421-15F2-4DF5-8738-8F61CA072AB2 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Mon, 26 Jun 2017 08:48:51 +0200 Subject: Re: Java 8 Date/Time API Extension Methods Message-Id: <79D7185B-CE2A-48CB-BE65-467E45E26F0F@googlemail.com> References: <1496920151.10302.14.camel@winder.org.uk> <1496921651.10302.16.camel@winder.org.uk> In-Reply-To: To: users@groovy.apache.org X-Mailer: iPad Mail (14D27) --Apple-Mail-F3F83421-15F2-4DF5-8738-8F61CA072AB2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Right Ahm, Good point. Backward compatibility helps not only us old-time groovy ppl but= also the new generation of converts to Groovy =F0=9F=91=8D=E2=9C=85 Sent from my iPad > On 26 Jun 2017, at 08:10, Ahm Avoby wrote: >=20 > Hi Jim, >=20 > @static parse(): I am with you on keeping the Java 8 API ordering, but I w= ould not jettison the upto and downto methods, as to not confuse people swit= ching from Java 8 to Groovy. >=20 > Cheers, > Ahm >=20 >=20 > Joe Wolf schrieb am So., 25. Juni 2017, 23:32: >> Goodtimes 1.1 is out with new extension methods on the zone-based types, e= ffectively 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. >>=20 >> 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 arg= ument 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'v= e aimed to be consistent with the Groovy JDK thus far, I'm leaning towards f= ollowing the Java 8 API ordering in this case. >>=20 >> On the other side of the coin, I am contemplating jettisoning the upto an= d downto methods. Since the java.time types are Comparable and goodtimes add= s next() and previous() methods, the range operator can be used to replicate= their function >>=20 >> earlier.upto(later) {} --> (earlier..later).each {} >> later.downto(earlier) {} --> (later..earlier).each {} >>=20 >> I'm also questioning the existence of the getAt(int calendarField) method= s. On the downside, it's munging the older java.util API with the new; on th= e upside, I don't have to explicitly import java.time.temporal.ChronoField. j= ava.util.Calendar comes for free. >>=20 >> -Joe >>=20 >>> On Fri, Jun 9, 2017 at 8:51 AM, Guillaume Laforge w= rote: >>> Keep us updated on the new extensions, and once you're happy with what y= ou have come up with, I believe it'd really be awesome to have it integrated= . >>>=20 >>> Guillaume >>>=20 >>>=20 >>>> On Fri, Jun 9, 2017 at 5:07 AM, Joe Wolf wrote: >>>> +1 for me. I think it's a good idea. >>>>=20 >>>> Not everything in the current API may be worthwhile to have as part of G= roovy proper, though. For example, the bridging methods from the java.time c= lasses back to Date and Calendar could be unnecessarily promoting the latter= 's usage. >>>>=20 >>>> 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. >>>>=20 >>>> -Joe >>>>=20 >>>>> On Thu, Jun 8, 2017 at 7:52 PM, Mario Garcia wr= ote: >>>>> +1=20 >>>>>=20 >>>>> I think Many Groovy applications could benefit from having this in Gro= ovy. >>>>>=20 >>>>> 2017-06-09 1:02 GMT+02:00 Paul King : >>>>>> +1 from me, but I'd be keen to hear Joe's thoughts? >>>>>>=20 >>>>>> Cheers, Paul. >>>>>>=20 >>>>>>=20 >>>>>>> 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 wro= te: >>>>>>> >> > On Wed, 2017-06-07 at 14:38 +0000, S=C3=B8ren Berg Glasius wrot= e: >>>>>>> >> > > 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 t= ime >>>>>>> >> > and >>>>>>> >> > date related? >>>>>>> >> >>>>>>> >> I think this falls into a category of "hope" or "wish", rather th= an >>>>>>> >> "assumption" :-) >>>>>>> > >>>>>>> > True, but I was hoping that unlike a large percentage of Java >>>>>>> > developers who are hugely reluctant to learn anything new they do n= ot >>>>>>> > already know (*), Groovy developers were very much into using the b= est >>>>>>> > new idiomatic ways of doing things (well except for stuff that is j= ust >>>>>>> > fashionably trendy for a few days) and keeping their codebases up t= o >>>>>>> > date with up-to-date Groovy. >>>>>>> > >>>>>>> > Please do not shatter my illusions. >>>>>>>=20 >>>>>>> haha! >>>>>>>=20 >>>>>>> Okay, I could convince myself that it is indeed so with Groovy devel= opers. :-) >>>>>>>=20 >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > (*) 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.winde= r@ekiga.net >>>>>>> > 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.or= g.uk >>>>>>> > London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> --=20 >>> Guillaume Laforge >>> Apache Groovy committer & PMC Vice-President >>> Developer Advocate @ Google Cloud Platform >>>=20 >>> Blog: http://glaforge.appspot.com/ >>> Social: @glaforge / Google+ >>=20 --Apple-Mail-F3F83421-15F2-4DF5-8738-8F61CA072AB2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Right Ahm,
Good point. Backward compatibility helps not only us old-time groov= y ppl but also the new generation of converts to Groovy =F0=9F=91=8D=E2=9C=85=

Sent from my iPad

On 26 Jun 2017, at 08:10, Ahm Avoby &= lt;aliencheckout@gmail.com>= ; wrote:

Hi Jim,

@static p= arse(): I am with you on keeping the Java 8 API ordering, but I would n= ot jettison the upto and downto methods, as to not confuse people switc= hing from Java 8 to Groovy.

Cheers,
Ahm

=
Joe Wolf <joewolf@gmail.com> schrieb am So., 25. Juni 201= 7, 23:32:
Goodtimes 1= .1 is out with new extension methods on the zone-based types, effectively co= vering the entire java.time.* package (except for Clock, which I haven't fou= nd 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. Alt= hough I've aimed to be consistent with the Groovy JDK thus far, I'm leaning t= owards following the Java 8 API ordering in this case.

<= div>On the other side of the coin, I am contemplating jettisoning the upto a= nd downto methods. Since the java.time types are Comparable and goodtimes ad= ds next() and previous() methods, the range operator can be used to replicat= e their function

earlier.upto(later) {} --> (= earlier..later).each {}
later.downto(earlier) {} --> (late= r..earlier).each {}

I'm also questioning the existe= nce of the getAt(int calendarField) methods. On the downside, it's munging t= he older java.util API with the new; on the upside, I don't have to explicit= ly import java.time.temporal.ChronoField. java.util.Calendar comes for free.=

-Joe
On Fri, Jun 9, 2017 at 8:51 AM, Guillaume Laforg= e <glaforge@gmail.com> wrote:
Keep us updated on the new extensions, and once you're ha= ppy with what you have come up with, I believe it'd really be awesome to hav= e it integrated.

Guillaume

On Fri, Jun 9, 2017 at 5:07 AM, Joe Wolf <joewol= f@gmail.com> 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, thou= gh. For example, the bridging methods from the java.time classes back to Dat= e and Calendar could be unnecessarily promoting the latter's usage.

By the way, I'm currently working to add extension methods t= o the java.time types involving ZoneId and ZoneOffset. I hope to have that c= ompleted in a couple of weeks or so.

-= Joe

On Thu, Jun 8, 20= 17 at 7:52 PM, Mario Garcia <mario.ggar@gmail.com> wrote:
+1 

I think Many Groovy applications could benefit from having this in Groovy.<= /div>

2017-06-09 1:02 GMT+02:00 Paul King <paulk@asert.com.au>:
+1 from me, but I'd b= e 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> wrote:=
On 8 June 2017 at 13:34, Russel Wind= er <russel@wind= er.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 wro= te:
>> > > 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 t= ime
>> > 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<= br> > new idiomatic ways of doing things (well except for stuff that is just<= br> > 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&nbs= p;  voip: sip:russel.winder@ekiga.net
> 41 Buckmaster Road    m: +44 7770 465 077  &n= bsp;xmpp: russel@w= inder.org.uk
> London SW11 1EN, UK   w: www.russel.org.uk  skype: rus= sel_winder






--
Guillaume Laforge
Apache Groovy committer & PMC Vice-Pre= sident
Developer Advocate @ Google Cloud Platform
<= div>
= --Apple-Mail-F3F83421-15F2-4DF5-8738-8F61CA072AB2--