1) Very much in favor of "parse this String with this pattern" (for all the
reasons given) :-)2) Agree that "strict/unit/exact" should be replaced by more
intuitive / self explanatory alternatives if possible.Cheers,mg
-------- Ursprüngliche Nachricht --------Von: Joe Wolf <joew...@gmail.com>
Datum: 21.03.18 18:57 (GMT+01:00) An: dev@groovy.apache.org, Paul King
<pa...@asert.com.au> Betreff: Re: Java 8 Date/Time API Extensions Methods
[GROOVY-8334]
(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 <pa...@asert.com.au> 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 <pa...@asert.com.au> wrote:
On Tue, Mar 20, 2018 at 2:19 AM, Joe Wolf <joew...@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 <glafo...@gmail.com> wrote:
Cool!
On Mon, Mar 19, 2018 at 5:06 PM, Daniel.Sun <sun...@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-PresidentDeveloper Advocate @ Google Cloud
Platform
Blog: http://glaforge.appspot.com/Social: @glaforge / Google+
