Groovy JDK Docs for 2.5.0

[Joe Wolf]

I noticed the Groovy 2.5.0 documentation reflects the extension methods
added to the java.time package and sub-packages (
http://groovy-lang.org/groovy-dev-kit.html#_working_with_date_time_types),
but the Groovy JDK docs do not mention them (http://groovy-lang.org/gdk.html
).

The necessary files are included in docs.gradle, however (
https://github.com/apache/groovy/blob/GROOVY_2_5_X/gradle/docs.gradle#L157-L159),
so perhaps this a publishing issue?

-Joe

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

[Joe Wolf]

(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('-MM-dd', '2000-01-01')
> LocalDate jan02 = LocalDate.parse('2000-01-02', '-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-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>
>>>>
>>>
>>>
>>
>

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

[Joe Wolf]

Thanks for the feedback and the pull! Glad there was consensus on the
strict upper bound view for upto/downto. Everything was essentially
straightforward one liners except for those two methods.

Daniel, in regards to being considered as a champion candidate, that's
flattering, but being able to contribute to Groovy core is honor enough.
I've benefited from Groovy for years and I've long wanted to give back to
the community.

-Joe

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+
> 
>

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

[Joe Wolf]

Here's a first stab at the documentation for the Date/Time API extensions:
http://bdkosher.github.io/groovy-3.0-alpha/html5/#_working_with_date_time_types


And in writing the documentation (as with writing unit tests), I got
feedback, prompting some minor changes:

1) using the DateTimeFormatter.ISO* formatters for implementing
getDateString(), getTimeString(), and getDateTimeString() instead of using
a localized FormatStyle.SHORT style. Besides making it easier to document
examples, I personally prefer "2018-03-17" to "3/17/18", even as an
American.

2) changing the behavior of the upto method (and downto) so that, when
using a custom unit of iteration that prevents the start value from being
incremented exactly to the end value, the method returns as soon as the
current value becomes strictly later than the end value. In my first stab
at it, the method returned when the current iteration value became later
than the end value _by at least one unit_. As a result, the closure could
be called with a value later than the end parameter, which seemed
undesirable. e.g.

def from = LocalDate.of(2018, Month.MARCH, 1)
def to =   LocalDate.of(2018, Month.MARCH, 2)

from.upto(to, ChronoUnit.MONTH) { date -> // iterate by one month at a time
println date
}

would print

2018-03-01
2018-04-01

This was because April 1st is less than a month after March 2nd:
march2nd.until(april1st,
ChronoUnit.MONTH) == 0, as explained in the docs
https://docs.oracle.com/javase/8/docs/api/java/time/temporal/Temporal.html#until-java.time.temporal.Temporal-java.time.temporal.TemporalUnit-


Anyways, the updated GDK docs are here, temporarily:
http://bdkosher.github.io/groovy-3.0-alpha/groovy-jdk/

Barring any substantial disagreement with inclusions or exclusions, I can
submit a PR and where we can discuss any minor implementation or
documentation details.

-Joe

On Mon, Feb 19, 2018 at 11:26 AM, Guillaume Laforge <glafo...@gmail.com>
wrote:

> Sounds awesome!
> Anyhow, I already like what I see, those methods sound very useful to me!
>
> On Mon, Feb 19, 2018 at 4:37 PM, Joe Wolf <joew...@gmail.com> wrote:
>
>> Good idea--I should have thought of that earlier! I'll draft up some
>> documentation in a new section of the core-gdk.adoc file and post a link
>> for review.
>>
>> -Joe
>>
>> On Mon, Feb 19, 2018 at 4:50 AM, Guillaume Laforge <glafo...@gmail.com>
>> wrote:
>>
>>> This looks very complete, at first sight, that's really wonderful!
>>> I'm really looking forward to seeing that integrated.
>>>
>>> Did you also have a pointer to a doc / page / blog which shows those
>>> methods in action?
>>> (which we could potentially add to our online documentation)
>>>
>>> Guillaume
>>>
>>> On Mon, Feb 19, 2018 at 12:16 AM, Joe Wolf <joew...@gmail.com> wrote:
>>>
>>>> I've finally gotten around to adding extension methods to the Groovy
>>>> JDK for the java.time types. See https://issues.apache.org/
>>>> jira/browse/GROOVY-8334 for reference.
>>>>
>>>> I've generated a copy of the Groovy JDK apidocs with my current changes
>>>> here: http://bdkosher.github.io/groovy-3.0-alpha/groovy-jdk/
>>>> <http://bdkosher.github.io/groovy-3.0-alpha/groovy-jdk/>
>>>>
>>>> The additions are in the java.time and java.time.temporal packages,
>>>> obviously, as well as some "since 3.0" methods in java.util.Date and
>>>> java.util.Calendar
>>>>
>>>> I thought it was worthwhile to open up these API changes for discussion
>>>> here before submitting a PR. There may be things included which should not
>>>> be or things not included that should.
>>>>
>>>> -Joe
>>>>
>>>
>>>
>>>
>>> --
>>> 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>
>>>
>>
>>
>
>
> --
> 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>
>

Re: Java 8 Date/Time API Extensions Methods [GROOVY-8334]

[Joe Wolf]

Good idea--I should have thought of that earlier! I'll draft up some
documentation in a new section of the core-gdk.adoc file and post a link
for review.

-Joe

On Mon, Feb 19, 2018 at 4:50 AM, Guillaume Laforge <glafo...@gmail.com>
wrote:

> This looks very complete, at first sight, that's really wonderful!
> I'm really looking forward to seeing that integrated.
>
> Did you also have a pointer to a doc / page / blog which shows those
> methods in action?
> (which we could potentially add to our online documentation)
>
> Guillaume
>
> On Mon, Feb 19, 2018 at 12:16 AM, Joe Wolf <joew...@gmail.com> wrote:
>
>> I've finally gotten around to adding extension methods to the Groovy
>> JDK for the java.time types. See https://issues.apache.org/
>> jira/browse/GROOVY-8334 for reference.
>>
>> I've generated a copy of the Groovy JDK apidocs with my current changes
>> here: http://bdkosher.github.io/groovy-3.0-alpha/groovy-jdk/
>> <http://bdkosher.github.io/groovy-3.0-alpha/groovy-jdk/>
>>
>> The additions are in the java.time and java.time.temporal packages,
>> obviously, as well as some "since 3.0" methods in java.util.Date and
>> java.util.Calendar
>>
>> I thought it was worthwhile to open up these API changes for discussion
>> here before submitting a PR. There may be things included which should not
>> be or things not included that should.
>>
>> -Joe
>>
>
>
>
> --
> 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>
>

Re: Parrot and the ++ and -- operators

[Joe Wolf]

This isn't a good idea at all, but you can produce the C++ behavior by
overriding next() in a mutable fashion, e.g.

@groovy.transform.TupleConstructor
class Bar {
int value
Bar next() {
++value
this
}
}

Bar b = new Bar(0)
++(++(++b))
assert b.value == 3

But in reality, it's just eliminating the effects/ordering of re-assignment
by only keeping one instance of Bar in play.

-Joe

On Tue, Feb 14, 2017 at 12:10 PM, Jochen Theodorou 
wrote:

>
>
> On 13.02.2017 23:58, Thibault Kruse wrote:
>
>>
>>
>> On Feb 14, 2017 3:52 AM, "Jochen Theodorou" > > wrote:
>>
>>
>> Options:
>>
>> (2) do allow these post- and prefix operators only on
>> VariableExpressions, making the code above no longer compile
>>
>>
>> Just to be sure, a VariableExpression is an expression consisting only
>> if a variable name?
>>
>
> yes, but yes, you are right, there are also PropertyExpressions and
> ArrayExpressions... so I was narrowing it down too much.
>
> And this applies to both the pre and postfix ++ operator?
>> So ++i++ would also stop compiling?
>>
>
> yes
>
> So the question could be rephrased as: is there any good usecase for ++
>> outside the increment of a variable? Like
>> x = (((a * b)++)/c)--
>>
>
> yes... and that even if considering we call next() for ++. I could imagine
> some crazy DSL to use this... but should we still consider doing this
> breaking change?
>
> bye Jochen
>

Re: Parrot and the ++ and -- operators

[Joe Wolf]

Good to know I'll be able to use these patterns in Groovy 3...I think :)

-Joe

On Tue, Jan 24, 2017 at 11:00 AM, Daniel Sun 
wrote:

> Hi Joe,
>
>   I've added your sample code as test
> cases(https://github.com/danielsun1106/groovy-parser/commit/
> 9914682e53fb2fe3d4bb335c8153e61066cea317).
> Parrot has same result with the old parser ;)
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: http://groovy.329449.n5.
> nabble.com/Parrot-and-the-and-operators-tp5737960p5737973.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.
>

Parrot and the ++ and -- operators

[Joe Wolf]

I accidentally discovered that Groovy 2, in contrast to Java, allows you to
apply the ++ and -- operators to the left and right sides of variables
simultaneously.

int i = 0
++i++
assert i == 1

and you can also chain them in a single statement provided you apply parens

int i = 0
((i++)++)++
assert i == 1
++(++(++i))
assert i == 2
++(++(++i++)++)++
assert i == 3

I can understand allowing the chaining syntax, considering that it's
roughly equivalent to next().next().next(), but as far as I reckon, being
able to use these operators in such a way has no practical purpose.

I haven't tried this code with the Groovy 3 parser yet--I was wondering if
it supported the ++ and -- operators similarly.

-Joe

Re: Automatic closure coercion and delegate

[Joe Wolf]

+1

Would it be sensible/possible to add a Closure.FIRST_ARGUMENT resolve
strategy and include it in the default resolution chain? The 'it'-less
closure would behave as expected even without pre-assigning the delegate
(provided that length() was not defined by the delegate/owner). It'd still
probably be a good idea to automatically set the delegate anyways...just
throwing out some thoughts.

[Hi, all. This is my first post to the list--been a happy Groovy user since
version 1.5]

-Joe


On Mon, May 2, 2016 at 10:56 AM, Guillaume Laforge 
wrote:

> +1
>
> On Mon, May 2, 2016 at 4:44 PM, Cédric Champeau  > wrote:
>
>> Hi guys,
>>
>> I've been grumpy about this for a bit too long to keep it for myself, so
>> let me explain the issue :)
>>
>> Imagine you have a Java method that accepts a SAM type:
>>
>> interface Action {
>>void execute(T object)
>> }
>>
>> class Person {
>> String name
>> }
>>
>> void configure(Action config) {
>>config.execute(person)
>> }
>>
>> then, you can call it in Groovy like this:
>>
>> configure {
>>it.name = 'Bob'
>> }
>>
>> Whereas if we had a closure version, a nice and idiomatic way would be to
>> write:
>>
>> configure {
>>name = 'Bob'
>> }
>>
>> Note that in the `Action` version, we have to prefix everything with
>> "it.".
>>
>> My wish is to make automatic closure coercion automatically set the
>> delegate to the first argument, if available, and the delegation strategy
>> to delegate first.
>>
>> Basically, it is important to integrate with Java 8 style SAM types and
>> still benefit from a nicer Groovy DSL _without_ having to change the source
>> files. Typically, we don't have access to the JDK sources, so we have to
>> write:
>>
>> def max =['Cedric','Jochen','Guillaume', 'Paul'].stream()
>>   .mapToInt { it.length() }
>>   .max()
>>   .orElse(0)
>>
>> Where with this strategy we could use:
>>
>> def max =['Cedric','Jochen','Guillaume', 'Paul'].stream()
>>   .mapToInt { length() }
>>   .max()
>>   .orElse(0)
>>
>> Of course, it may look a bit superficial but it is super important for
>> nice DSLs like in Gradle. Typically, Gradle has a lot of domain objects
>> that use the `Action` interface above. Those actions allow the user to
>> configure the domain objects typically from plugins written in Java (where
>> you cannot use a closure). Since the `Closure` equivalent methods are
>> always the same and that it's super simple to forget to implement one,
>> Gradle chose to _not_ implement the `Closure` versions. Instead, they are
>> generated at runtime, so the objects are decorated with one `Closure`
>> method for each `Action` one.
>>
>> Unfortunately, this approach is defeated as soon as you want to use
>> static compilation: then, you have no choice but implementing the `Closure`
>> versions. This might be an option for Gradle (even though it would be very
>> tedious), but not for all cases (we could also do this using extension
>> methods, though, but really, you'd be doing this for _all_ domain objects).
>> I think I could write a code generator that takes all java classes and
>> generates an extension class with closure versions for all, also, but I'd
>> like to know first what you think of this idea...
>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Product Ninja & Advocate at Restlet 
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge  / Google+
> 
>