groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]
Date Wed, 21 Mar 2018 17:17:04 GMT
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 <paulk@asert.com.au> wrote:

>
>
> On Tue, Mar 20, 2018 at 2:19 AM, Joe Wolf <joewolf@gmail.com> 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 <glaforge@gmail.com>
>> wrote:
>>
>>> Cool!
>>>
>>> On Mon, Mar 19, 2018 at 5:06 PM, Daniel.Sun <sunlan@apache.org> 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 <http://twitter.com/glaforge> / Google+
>>> <https://plus.google.com/u/0/114130972232398734985/posts>
>>>
>>
>>
>

Mime
View raw message