From dev-return-4483-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Mon Mar 26 04:18:32 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 179E118063B for ; Mon, 26 Mar 2018 04:18:31 +0200 (CEST) Received: (qmail 5256 invoked by uid 500); 26 Mar 2018 02:18:30 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 5244 invoked by uid 99); 26 Mar 2018 02:18:30 -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 Mar 2018 02:18:29 +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 933121A08EA for ; Mon, 26 Mar 2018 02:18:29 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.293 X-Spam-Level: *** X-Spam-Status: No, score=3.293 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=asert-com-au.20150623.gappssmtp.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 xCQYJuA6qPOr for ; Mon, 26 Mar 2018 02:18:26 +0000 (UTC) Received: from mail-ot0-f176.google.com (mail-ot0-f176.google.com [74.125.82.176]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id D79B95F4EB for ; Mon, 26 Mar 2018 02:18:25 +0000 (UTC) Received: by mail-ot0-f176.google.com with SMTP id m22-v6so18995934otf.10 for ; Sun, 25 Mar 2018 19:18:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=asert-com-au.20150623.gappssmtp.com; s=20150623; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=62k8mBALDaPAEM3d2t3XLNjo736d66jOQk9OdeeIzKU=; b=O1WQslQfYuWjGrOSCfLN6QUAaGug1+AH8eC9LXa/wH6PUC5L6HeCpgqOxQTsHWRH7c MQ3oQVqQiwZOC0PjL602nx/TUhCath2stG4QNPB5oNAmFcFD4nkQ3N+kuKPAyRDIO4Si T+b//MwZOIiU9kPCRSxUqaoiRRsqFadfGvO452lAdBePjpRg6f9LF8zOOAO3retAi/2R zvMemigp2w9bADeflzkd4aehk8Xe1HrLLVS9VmUKzraT78PBx1aM978B7XI/Hf+OT+cg mUC/zf+JWN6XBGn8gfGXboU0KdDzx6zWBX5BTYSiz/7/gQgmzyVzJgZr8xkjK7tDBFFj AlOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=62k8mBALDaPAEM3d2t3XLNjo736d66jOQk9OdeeIzKU=; b=NqN8/iWAxsKA9JWGnLkUtu+I07b+AWnMO4JsV/hjGTY+v2D8T1Rn3smw+TBPJwVKud 8L6XLBeHx5WowmZuBIVn4Mcmcuy60+cMDKsUeaBvMPr6g1lGqPahIfFpjGUs8kpNYvVe qpfWvlyNH14mwOq6Lz1ac22auy6vGMiIqhxooaXSnJ4kFcM8GmcXwlMPNkyy+te3/R0/ lu/RJI9RxDTx9lsxFheutQpGKcGnqRBdY7UAm3GOk0Ql1zv1By92UUA6XxiagL/bSIB5 XaXL/sOxJ/natBDDdGM+VGh+UFKWQzZliCLB+c/oXgKRdUSWrJTpYD4Y0v1pv3oJZsB8 /VzA== X-Gm-Message-State: AElRT7FlAV/nX1p6/xzkO5X/sShhisFghMoFBAib2DVxcXR0ZVMkPJmA gS8Ut8SmFGSHu8B4v6FWOFlBxxHyH6i2kArF3YNI+w== X-Google-Smtp-Source: AG47ELuocXsFYmTHe9/ovBvf9yInKV/jXa5l08ozXrNi6geWQz8qOJ98JndBOIzViXs+B73KEZbL7AFaHwSZwwC2nnA= X-Received: by 2002:a9d:1f24:: with SMTP id x33-v6mr25917268otd.165.1522030704571; Sun, 25 Mar 2018 19:18:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.74.22.148 with HTTP; Sun, 25 Mar 2018 19:18:23 -0700 (PDT) Reply-To: paulk@asert.com.au In-Reply-To: References: <1521475584057-0.post@n5.nabble.com> From: Paul King Date: Mon, 26 Mar 2018 12:18:23 +1000 Message-ID: Subject: Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334] To: Joe Wolf Cc: dev@groovy.apache.org Content-Type: multipart/alternative; boundary="0000000000007bc90505684763b3" --0000000000007bc90505684763b3 Content-Type: text/plain; charset="UTF-8" I haven't had time to look at step variants yet but I'll leave the parse methods as is but add in some doco to warn people to expect differences to the legacy parse methods. On Thu, Mar 22, 2018 at 3:57 AM, Joe Wolf wrote: > (1) The parse method argument ordering was a tough call for me, but three > reasons led me to favor the current ordering. > > The primary reason was to be consistent with the new Date/Time API itself. > Most types have two static parse methods, e.g. > > static LocalDate parse(CharSequence value) > static LocalDate parse(CharSequence value, DateTimeFormatter format) > > The new extension parse method is a more convenient form of the latter > method, which basically treats the formatter as an optional argument. > > The second reason is that the ordering reads better to me; no need for a > comma pause: "parse this String with this pattern" vs. "with this pattern, > parse this String" > > The third reason is that it could better support overriding the method in > the future to accept more than one pattern, akin to commons-lang DateUtil's > parseDate method (https://commons.apache.org/proper/commons-lang/apidocs/ > org/apache/commons/lang3/time/DateUtils.html#parseDate-java. > lang.String-java.lang.String...-) > > (2) In addition to the variation you mentioned (which I think is a good > idea), I was mulling yet another upto variation that takes an additional > argument that defines how to deal with the inclusivity of the end argument. > There are three variations as I see it: > - strict > - unit > - exact > > The names definitely need work, but it would work like this: consider > iterating from March 1st until March 2nd using a unit of Months > - "strict" = the current behavior--never let the current value exceed the > end value: e.g. closure is invoked with March 1st and the method returns > - "unit" = the behavior where the iteration stops as the current value is > greater than one unit from the target: e.g. closure is invoked once with > March 1st and once with April 1st before returning > - "exact" = this would mean that the end argument is included in the > iteration whether or not it's "landed on" exactly: e.g. the closure is > invoked once with March 1st and once with March 2nd > > But, given the complexity of even having to explain this and come up with > reasonable names for the optional "inclusivity" enum values, I find your > suggestion of stepUp(from, to, unit, amount) appealing. > > -Joe > > > On Wed, Mar 21, 2018 at 1:17 PM, Paul King wrote: > >> Okay, I had a bit more of a look at the methods. I think the upto >> behavior is fine - though see my comment below. I have two overall comments: >> >> (1) Parse method argument order are reversed to existing methods, e.g.: >> >> Date jan01 = Date.parse('yyyy-MM-dd', '2000-01-01') >> LocalDate jan02 = LocalDate.parse('2000-01-02', 'yyyy-MM-dd') >> >> Okay if I swap the order of arguments around for consistency with the >> existing Date methods? >> >> (2) I was pondering upto variations. Groovy has a step method in addition >> to upto which is used when iterating in multiples. It lets you specify an >> increment amount but not a unit, so is not an exact match. It seems like >> having a method that had an increment amount might be useful, e.g. stepping >> between two dates in fortnightly intervals. I guess there are numerous ways >> we could implement such functionality. My current thinking is rename the >> current 3-arg upto method to step but add a fourth amount argument. The >> 3-arg downto could be removed. The step method counts up or down depending >> on whether from or to is biggest. It throws an "infinite loop" runtime >> exception given a zero amount. We could follow that behavior. >> >> Thoughts? >> >> Cheers, Paul. >> >> >> On Tue, Mar 20, 2018 at 12:48 PM, Paul King wrote: >> >>> >>> >>> On Tue, Mar 20, 2018 at 2:19 AM, Joe Wolf wrote: >>> >>>> [...] Glad there was consensus on the strict upper bound view for >>>> upto/downto. [...] >>>> >>> >>> Being at the conference the last week, I didn't get time to look at that >>> properly. It worries me that we'd have a different semantics for >>> upto/downto compared to other classes but I can see the need for the >>> proposed functionality. >>> I was thinking that we might need to make the same kind of distinction >>> that we do for Range, e.g. inclusive vs exclusive or that Java does in the >>> Streams api, open/closed. But I'll play a little more and propose something >>> more concrete. >>> >>> >>> >>>> On Mon, Mar 19, 2018 at 12:07 PM, Guillaume Laforge >>> > wrote: >>>> >>>>> Cool! >>>>> >>>>> On Mon, Mar 19, 2018 at 5:06 PM, Daniel.Sun wrote: >>>>> >>>>>> Merged. >>>>>> https://github.com/apache/groovy/pull/674 >>>>>> >>>>>> Cheers, >>>>>> Daniel.Sun >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Guillaume Laforge >>>>> Apache Groovy committer & PMC Vice-President >>>>> Developer Advocate @ Google Cloud Platform >>>>> >>>>> Blog: http://glaforge.appspot.com/ >>>>> Social: @glaforge / Google+ >>>>> >>>>> >>>> >>>> >>> >> > --0000000000007bc90505684763b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I haven't had time to look at step variants yet but I&= #39;ll leave the parse methods as is but add in some doco to warn people to= expect differences to the legacy parse methods.

On Thu, Mar 22, 2018 at 3:57 AM, Joe W= olf <joewolf@gmail.com> wrote:
(1) The parse method argument ordering was a tough ca= ll for me, but three reasons led me to favor the current ordering.=C2=A0
The primary reason was to be consistent with the new Date/= Time API itself. Most types have two static parse methods, e.g.

static LocalDate parse(CharSequence value)=C2=A0
static L= ocalDate parse(CharSequence value, DateTimeFormatter format)

=
The new extension parse method is a more convenient form of the = latter method, which basically treats the formatter as an optional argument= .

The second reason is that the ordering reads bet= ter to me; no need for a comma pause: "parse this String with this pat= tern" vs. "with this pattern, parse this String"
<= br>
The third reason is that it could better support overriding t= he method in the future to accept more than one pattern, akin to commons-la= ng DateUtil's parseDate method (https://com= mons.apache.org/proper/commons-lang/apidocs/org/apache/commons/la= ng3/time/DateUtils.html#parseDate-java.lang.String-java.lang.Stri= ng...-)

(2) In addition to the variation = you mentioned (which I think is a good idea), I was mulling yet another upt= o variation that takes an additional argument that defines how to deal with= the inclusivity of the end argument. There are three variations as I see i= t:
- strict
- unit
- exact

The names definitely need work, but it would work like this: conside= r iterating from March 1st until March 2nd using a unit of Months
- "strict" =3D the current behavior--never let the current value= exceed the end value: e.g. closure is invoked with March 1st and the metho= d returns
- "unit" =3D the behavior where the iteration= stops as the current value is greater than one unit from the target: e.g. = closure is invoked once with March 1st and once with April 1st before retur= ning
- "exact" =3D this would mean that the end argumen= t is included in the iteration whether or not it's "landed on"= ; exactly: e.g. the closure is invoked once with March 1st and once with Ma= rch 2nd

But, given the complexity of even having t= o explain this and come up with reasonable names for the optional "inc= lusivity" enum values, I find your suggestion of stepUp(from, to, unit= , amount) appealing.

-Joe


On Wed, Mar 21, 2018 at 1:17 PM, Paul King <paulk@asert.= com.au> wrote:
Okay, I had a bit more of a look at the methods. I think the upto beha= vior is fine - though see my comment below. I have two overall comments:
(1) Parse method argument order are reversed to existing m= ethods, e.g.:

Date jan01 =3D Date.parse('= yyyy-MM-dd', '2000-01-01')
LocalDate jan02= =3D LocalDate.parse('2000-01-02', 'yyyy-MM-dd')

Okay if I swap the order of arguments around for consi= stency with the existing Date methods?

(2) I was p= ondering upto variations. Groovy has a step method in addition to upto whic= h is used when iterating in multiples. It lets you specify an increment amo= unt but not a unit, so is not an exact match. It seems like having a method= that had an increment amount might be useful, e.g. stepping between two da= tes in fortnightly intervals. I guess there are numerous ways we could impl= ement such functionality. My current thinking is rename the current 3-arg u= pto method to step but add a fourth amount argument. The 3-arg downto could= be removed. The step method counts up or down depending on whether from or= to is biggest. It throws an "infinite loop" runtime exception gi= ven a zero amount. We could follow that behavior.

= Thoughts?

Cheers, Paul.

=

On Tue, = Mar 20, 2018 at 12:48 PM, Paul King <paulk@asert.com.au> wr= ote:


On Tue, Mar 20, 2018 at 2:19 AM,= Joe Wolf <joewolf@gmail.com> wrote:
[...] Glad there was consensus on the strict up= per bound view for upto/downto. [...]

Being at the conference the last week, I didn't get time to look at th= at properly. It worries me that we'd have a different semantics for upt= o/downto compared to other classes but I can see the need for the proposed = functionality.
I was thinking that we might need to make the same= kind of distinction that we do for Range, e.g. inclusive vs exclusive or t= hat Java does in the Streams api, open/closed. But I'll play a little m= ore and propose something more concrete.=C2=A0

=C2=A0
<= /div>
On Mon, Mar 19, 2018 at 12:07 PM, Guillaume Laforge &= lt;glaforge@gmail.c= om> wrote:
Cool!
On Mon, Mar 19, 2018 at 5:06 PM, Daniel.Sun <= sunlan@apache.org> wrote:
M= erged.
https://github.com/apache/groovy/pull/674

Cheers,
Daniel.Sun



--
Sent from: http://groovy.329449.n5.nabble<= wbr>.com/Groovy-Dev-f372993.html



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






--0000000000007bc90505684763b3--