+1 (Binding)
On Tue, Dec 1, 2020 at 4:11 PM Paul King wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 4.0.0-alpha-2 release!
>
> NOTE: If building from source, please observe the slightly changed
> instructions for bootstrapping gradle in the README.a
Traditional "for" (first example) and ARM "try" (last example) support local
variable declarations that are scoped to the statement. In light of the
upcoming "instanceof" enhancement in Java, I was thinking about possible
alternatives for declaring local variables that have statement scope.
fo
Maybe the "if" could forward declare the name(s) like this when not relying on
Groovy truth:
if (def x; (x = ...) != null) {
}
-
if (def x = ...) { // tests Groovy truth in this form; may be wrapped in parens
to check something else about "x"
}
Hello there,
when touching this stuff, it would be extremely desirable primarily to fix the
scoping/obscuring of same-named variables, which Groovy at the moment does
wrong, same as the demented Java thing:
===
89 ocs /tmp> /usr/local/groovy-4.0.0-alpha-1/bin/groovy q
org.codehaus.groovy.contr
Hi OC,
I think that generally speaking, hiding/masking an outer variable like
that is a quite undesireable coding style, so I like the current Groovy
behavior (even if it deviates from C, evidently - I never used code like
that in C, so I did not even know it was valid ;-) ).
What specific u
Hi Eric,
my take inline:
On 02/12/2020 17:34, Milles, Eric (TR Technology) wrote:
Traditional "for" (first example) and ARM "try" (last example) support
local variable declarations that are scoped to the statement. In
light of the upcoming "instanceof" enhancement in Java, I was thinking
a
MG,
the idea is very plain:
- if you don't need to nest same-named variables, there's no harm, you just
don't do that, and all's well and swell — the danger you do that inadvertently
and mess up your code is nonzero, but extremely small;
- if you happen to need that — typically, if you are copy
Hi OC,
1. Is there a reason you cannot put your "well-tested inner code" in a
seperate method, thereby making the code cleaner and avoiding the
name clash problem altogether ? In any case that is not a strong
argument in my eyes: Just copy & paste the code into a seperate
editor and s
The vote has passed with 3 binding +1 votes, one other +1 vote and no other
votes.
I'll proceed with next steps.
Cheers, Paul.
On Mon, Nov 30, 2020 at 3:36 PM Paul King wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.4.21 release!
>
> This release i
The vote has passed with 4 binding +1 votes, one other +1 vote and no other
votes.
I'll proceed with next steps.
Cheers, Paul.
On Mon, Nov 30, 2020 at 3:55 PM Paul King wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 2.5.14 release!
>
> This release i
The vote has passed with 4 binding +1 votes, one other +1 vote and no other
votes.
I'll proceed with next steps.
Cheers, Paul.
On Mon, Nov 30, 2020 at 5:00 PM Paul King wrote:
>
> Dear development community,
>
> I am happy to start the VOTE thread for a Groovy 3.0.7 release!
>
> This release in
11 matches
Mail list logo
