[jira] [Updated] (GROOVY-7569) PowerAsserts should print results more verbosely and safer

2017-08-27 Thread Paul King (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-7569?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King updated GROOVY-7569:
--
Description: 
The output of buffer evaluation results in PowerAsserts hides a lot of useful 
information from the user.

This is similar to https://issues.apache.org/jira/browse/GROOVY-7568, but 
independent.

Discussed here:
http://groovy.329449.n5.nabble.com/Should-PowerAsserts-be-more-verbose-td5727255.html
https://groups.google.com/d/msg/spockframework/XbR-McgaAss/-wtkD1X1BAAJ

In particular Strings are printed without surrounding quotes, collections are 
printed without telling whether they are Lists, Maps, Sets, or Ranges. Ranges 
are printed fully as lists (which can be unnecessarily long).

An implementation is almost done at 
https://github.com/tkruse/incubator-groovy/tree/pretty

The downside or more information is that this output could be regarded as "too 
noisy".

  was:
The output of buffer evaluation results in PowerAsserts hides a lot of useful 
information from the user.

This is similar to https://issues.apache.org/jira/browse/GROOVY-7568, but 
independent.

Discussed here:
http://groovy.329449.n5.nabble.com/Should-PowerAsserts-be-more-verbose-td5727255.html
https://groups.google.com/d/msg/spockframework/XbR-McgaAss/-wtkD1X1BAAJ

In particular Strings are printed without surrounding hyphens, collections are 
printed without telling whether they are Lists, Maps, Sets, or Ranges. Ranges 
are printed fully as lists (which can be unnecessarily long).

An implementation is almost done at 
https://github.com/tkruse/incubator-groovy/tree/pretty

The downside or more information is that this output could be regarded as "too 
noisy".


> PowerAsserts should print results more verbosely and safer
> --
>
> Key: GROOVY-7569
> URL: https://issues.apache.org/jira/browse/GROOVY-7569
> Project: Groovy
>  Issue Type: Improvement
>Reporter: Thibault Kruse
>
> The output of buffer evaluation results in PowerAsserts hides a lot of useful 
> information from the user.
> This is similar to https://issues.apache.org/jira/browse/GROOVY-7568, but 
> independent.
> Discussed here:
> http://groovy.329449.n5.nabble.com/Should-PowerAsserts-be-more-verbose-td5727255.html
> https://groups.google.com/d/msg/spockframework/XbR-McgaAss/-wtkD1X1BAAJ
> In particular Strings are printed without surrounding quotes, collections are 
> printed without telling whether they are Lists, Maps, Sets, or Ranges. Ranges 
> are printed fully as lists (which can be unnecessarily long).
> An implementation is almost done at 
> https://github.com/tkruse/incubator-groovy/tree/pretty
> The downside or more information is that this output could be regarded as 
> "too noisy".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GROOVY-7568) Groovysh output should be more safe, verbose about types and String output

2017-08-27 Thread Paul King (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-7568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King updated GROOVY-7568:
--
Description: 
The output of buffer evaluation results in Groovy hides a lot of useful 
information from the user.

In particular Strings are printed without surrounding quotes, collections are 
printed without telling whether they are Lists, Maps, Sets, or Ranges. Ranges 
are printed fully as lists (which can be unnecessarily long).

An implementation is almost done at 
https://github.com/tkruse/incubator-groovy/tree/pretty

Both Python and Ruby shells follow the approach of printing strings as 
code-strings (with quotes and escaping).

The downside or more information is that this output could be regarded as "too 
noisy".

  was:
The output of buffer evaluation results in Groovy hides a lot of useful 
information from the user.

In particular Strings are printed without surrounding hyphens, collections are 
printed without telling whether they are Lists, Maps, Sets, or Ranges. Ranges 
are printed fully as lists (which can be unnecessarily long).

An implementation is almost done at 
https://github.com/tkruse/incubator-groovy/tree/pretty

Both Python and Ruby shells follow the approach of printing strings as 
code-strings (with hyphens and escaping).

The downside or more information is that this output could be regarded as "too 
noisy".


> Groovysh output should be more safe, verbose about types and String output
> --
>
> Key: GROOVY-7568
> URL: https://issues.apache.org/jira/browse/GROOVY-7568
> Project: Groovy
>  Issue Type: Improvement
>  Components: Groovysh
>Reporter: Thibault Kruse
>Priority: Minor
>
> The output of buffer evaluation results in Groovy hides a lot of useful 
> information from the user.
> In particular Strings are printed without surrounding quotes, collections are 
> printed without telling whether they are Lists, Maps, Sets, or Ranges. Ranges 
> are printed fully as lists (which can be unnecessarily long).
> An implementation is almost done at 
> https://github.com/tkruse/incubator-groovy/tree/pretty
> Both Python and Ruby shells follow the approach of printing strings as 
> code-strings (with quotes and escaping).
> The downside or more information is that this output could be regarded as 
> "too noisy".



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread Paul King (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King updated GROOVY-8300:
--
Description: 
When defined on a method or constructor, all parameters of that 
method/constructor will be final. When applied on a class, the annotation 
applies to all methods/constructors.

Discussion points:
# Should visibility matter, e.g. would it apply to all public, protected, 
private, etc. members, or does there need to be some ability to customise? 
*Current thinking*: it should apply to all methods. We can always introduce an 
additional annotation attribute at a later point if there is demand.
# Should there be support for 'includes' or 'excludes' functionality? *Current 
thinking*: don't support this for now. The annotation can be applied on 
multiple methods/constructors if finer granularity than the class level is 
required.
# Should the annotation apply to fields/properties? Applying 'final' to a 
field/property seems to be more efficient than applying @AutoFinal but would 
there ever be a desire to apply such an annotation to all fields/properties? 
*Current thinking*: don't support this for now. An annotation attribute could 
be added later if we wanted to optionally turn such extra cases on.
# Should it apply to synthetic methods/constructors added by the compiler/other 
transforms?
# What phase should this run at? It needs to be before the (incubating) final 
variable analyser is run.
# We should have tests to confirm that there are no adverse interactions with 
other language features, e.g. default parameter values.

  was:
When defined on a method or constructor, all parameters of that 
method/constructor will be final. When applied on a class, the annotation 
applies to all methods/constructors.

Still to be determined:
# Should visibility matter, e.g. would it apply to all public, protected, 
private, etc. members, or does there need to be some ability to customise?
# Should the annotation apply to fields/properties? Applying 'final' to a 
field/property seems to be more efficient than applying @AutoFinal but would 
there ever be a desire to apply such an annotation to all fields/properties?


> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Discussion points:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise? 
> *Current thinking*: it should apply to all methods. We can always introduce 
> an additional annotation attribute at a later point if there is demand.
> # Should there be support for 'includes' or 'excludes' functionality? 
> *Current thinking*: don't support this for now. The annotation can be applied 
> on multiple methods/constructors if finer granularity than the class level is 
> required.
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties? 
> *Current thinking*: don't support this for now. An annotation attribute could 
> be added later if we wanted to optionally turn such extra cases on.
> # Should it apply to synthetic methods/constructors added by the 
> compiler/other transforms?
> # What phase should this run at? It needs to be before the (incubating) final 
> variable analyser is run.
> # We should have tests to confirm that there are no adverse interactions with 
> other language features, e.g. default parameter values.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Comment Edited] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread Paul King (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143369#comment-16143369
 ] 

Paul King edited comment on GROOVY-8300 at 8/28/17 4:57 AM:


I tend to agree with your comments - though I am inclined to just leave the 
name as is. I'll update the description.


was (Author: paulk):
I tend to agree with your comments. I'll update the description.

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread Paul King (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143369#comment-16143369
 ] 

Paul King commented on GROOVY-8300:
---

I tend to agree with your comments. I'll update the description.

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (GROOVY-8303) VerifyError for nested class this call to static method

2017-08-27 Thread John Wagenleitner (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John Wagenleitner resolved GROOVY-8303.
---
   Resolution: Fixed
 Assignee: John Wagenleitner
Fix Version/s: 2.5.0-beta-2

> VerifyError for nested class this call to static method
> ---
>
> Key: GROOVY-8303
> URL: https://issues.apache.org/jira/browse/GROOVY-8303
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.5.0-beta-1
>Reporter: John Wagenleitner
>Assignee: John Wagenleitner
> Fix For: 2.5.0-beta-2
>
>
> {code}
> class Base {
> static class Nested {
> private String b
> static String getData() { return "ABCD" }
> Nested() { this(getData()) }
> Nested(String b) { this.b = b }
> String toString() { b }
> }
> }
> assert new Base.Nested().toString() == 'ABCD'
> {code}
> Results in 
> {code}
> java.lang.VerifyError: (class: Base$Nested, method:  signature: ()V) 
> Expecting to find object/array on stack.
> {code}
> The same code works if a top-level class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GROOVY-8303) VerifyError for nested class this call to static method

2017-08-27 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143350#comment-16143350
 ] 

ASF GitHub Bot commented on GROOVY-8303:


Github user asfgit closed the pull request at:

https://github.com/apache/groovy/pull/593


> VerifyError for nested class this call to static method
> ---
>
> Key: GROOVY-8303
> URL: https://issues.apache.org/jira/browse/GROOVY-8303
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.5.0-beta-1
>Reporter: John Wagenleitner
>
> {code}
> class Base {
> static class Nested {
> private String b
> static String getData() { return "ABCD" }
> Nested() { this(getData()) }
> Nested(String b) { this.b = b }
> String toString() { b }
> }
> }
> assert new Base.Nested().toString() == 'ABCD'
> {code}
> Results in 
> {code}
> java.lang.VerifyError: (class: Base$Nested, method:  signature: ()V) 
> Expecting to find object/array on stack.
> {code}
> The same code works if a top-level class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] groovy pull request #593: GROOVY-8303: VerifyError for nested class this cal...

2017-08-27 Thread asfgit 
Github user asfgit closed the pull request at:

https://github.com/apache/groovy/pull/593


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (GROOVY-8303) VerifyError for nested class this call to static method

2017-08-27 Thread ASF GitHub Bot (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143236#comment-16143236
 ] 

ASF GitHub Bot commented on GROOVY-8303:


GitHub user jwagenleitner opened a pull request:

https://github.com/apache/groovy/pull/593

GROOVY-8303: VerifyError for nested class this call to static method



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jwagenleitner/groovy 8303-VerifyError-Nested

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/593.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #593


commit 29614bfa2ef1a3c57412b8148125d43b1911dc43
Author: John Wagenleitner 
Date:   2017-08-27T21:23:29Z

GROOVY-8303: VerifyError for nested class this call to static method




> VerifyError for nested class this call to static method
> ---
>
> Key: GROOVY-8303
> URL: https://issues.apache.org/jira/browse/GROOVY-8303
> Project: Groovy
>  Issue Type: Bug
>Affects Versions: 2.5.0-beta-1
>Reporter: John Wagenleitner
>
> {code}
> class Base {
> static class Nested {
> private String b
> static String getData() { return "ABCD" }
> Nested() { this(getData()) }
> Nested(String b) { this.b = b }
> String toString() { b }
> }
> }
> assert new Base.Nested().toString() == 'ABCD'
> {code}
> Results in 
> {code}
> java.lang.VerifyError: (class: Base$Nested, method:  signature: ()V) 
> Expecting to find object/array on stack.
> {code}
> The same code works if a top-level class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] groovy pull request #593: GROOVY-8303: VerifyError for nested class this cal...

2017-08-27 Thread jwagenleitner 
GitHub user jwagenleitner opened a pull request:

https://github.com/apache/groovy/pull/593

GROOVY-8303: VerifyError for nested class this call to static method



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jwagenleitner/groovy 8303-VerifyError-Nested

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/groovy/pull/593.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #593


commit 29614bfa2ef1a3c57412b8148125d43b1911dc43
Author: John Wagenleitner 
Date:   2017-08-27T21:23:29Z

GROOVY-8303: VerifyError for nested class this call to static method




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Created] (GROOVY-8303) VerifyError for nested class this call to static method

2017-08-27 Thread John Wagenleitner (JIRA) 
John Wagenleitner created GROOVY-8303:
-

 Summary: VerifyError for nested class this call to static method
 Key: GROOVY-8303
 URL: https://issues.apache.org/jira/browse/GROOVY-8303
 Project: Groovy
  Issue Type: Bug
Affects Versions: 2.5.0-beta-1
Reporter: John Wagenleitner


{code}
class Base {
static class Nested {
private String b
static String getData() { return "ABCD" }
Nested() { this(getData()) }
Nested(String b) { this.b = b }
String toString() { b }
}
}
assert new Base.Nested().toString() == 'ABCD'
{code}

Results in 

{code}
java.lang.VerifyError: (class: Base$Nested, method:  signature: ()V) 
Expecting to find object/array on stack.
{code}

The same code works if a top-level class.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread mg (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143178#comment-16143178
 ] 

mg commented on GROOVY-8300:


As a side note: A similar result to @AutoFinalParams could also be achieved 
through IDE support, if the IDE could optionally hide the final keywords, and 
replace them e.g. through displaying final parameters in a different color. 
However 
# To my knowledge no such support currently exists e.g. in IntelliJ
# One is not always in an IDE environment (e.g. script development, application 
DSL)
# IDE support along the same line could also help making application of 
@AutoFinalParams more explicit

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread mg (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143170#comment-16143170
 ] 

mg commented on GROOVY-8300:


I think method visibility does not need to be taken into consideration because:
# Imho either one wants to be sure parameters cannot be changed by accident - 
or not, and I do not see how this could depend on whether a method is e.g. 
private or public
# But more importantly: I feel auto applying the final keyword to parameters 
under certain circumstances only would be confusing in practice, so I would 
argue against it.

> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread mg (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143168#comment-16143168
 ] 

mg commented on GROOVY-8300:


If e.g. a team decides all fields/properties shall be final by design (forcing 
(one-time-only) initialization by ctor only), I could see potential use for 
also having an "auto final" option for fields/properties. However since 
field/property declarations are typically given as one-per-line, reduction of 
clutter is less of an issue here. Also one might want to have a non-final field 
for debugging purposes, etc, so overall I do not see this as nearly as useful a 
feature in practice.

I would therefore suggest that this annotation should only apply to method 
parameters, and should accordingly be renamed @AutoFinalParams.


> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Closed] (GROOVY-8302) Delete me

2017-08-27 Thread mg (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mg closed GROOVY-8302.
--
Resolution: Invalid

> Delete me
> -
>
> Key: GROOVY-8302
> URL: https://issues.apache.org/jira/browse/GROOVY-8302
> Project: Groovy
>  Issue Type: Proposal
>Reporter: mg
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GROOVY-8302) Delete me

2017-08-27 Thread mg (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-8302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

mg updated GROOVY-8302:
---
   Priority: Trivial  (was: Major)
Description: (was: This proposal revisits the idea to change the 
semantics of the break, return, and continue keyword for closures that are used 
in a way that mimics classical Java block constructs such as if, for, or while.

Example 1:
{code}
// Iterate over all PERSON rows in the result set
sqe.forEachRow("select * from PERSON") { final row ->
  if(row.TAG == 0) { break } // Leave forEachRow loop
  if(row.TAG == 1) { return } // return from the method enclosing the 
forEachRow loop
  if(row.TAG == 2) { continue } // Move to next iteration in the forEachRow loop
}
{code}


Example 2:
{code}
// Encapsulate with statically imported helper method that catches exceptions 
and ignores them, if the passed parameter is true
execWithOptionalIgnoreErrors(ignoreErrorsQ) {
  final x = dangerousOperation() 
  if(x == 1) { return } // return from the enclosing method
  // Note: break & continue are not allowed here
}
{code})
Component/s: (was: Compiler)
Summary: Delete me  (was: break/return/continue support in "Appended 
Block Closures")

> Delete me
> -
>
> Key: GROOVY-8302
> URL: https://issues.apache.org/jira/browse/GROOVY-8302
> Project: Groovy
>  Issue Type: Proposal
>Reporter: mg
>Priority: Trivial
>




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GROOVY-8302) break/return/continue support in "Appended Block Closures"

2017-08-27 Thread mg (JIRA) 
mg created GROOVY-8302:
--

 Summary: break/return/continue support in "Appended Block Closures"
 Key: GROOVY-8302
 URL: https://issues.apache.org/jira/browse/GROOVY-8302
 Project: Groovy
  Issue Type: Proposal
  Components: Compiler
Reporter: mg


This proposal revisits the idea to change the semantics of the break, return, 
and continue keyword for closures that are used in a way that mimics classical 
Java block constructs such as if, for, or while.

Example 1:
{code}
// Iterate over all PERSON rows in the result set
sqe.forEachRow("select * from PERSON") { final row ->
  if(row.TAG == 0) { break } // Leave forEachRow loop
  if(row.TAG == 1) { return } // return from the method enclosing the 
forEachRow loop
  if(row.TAG == 2) { continue } // Move to next iteration in the forEachRow loop
}
{code}


Example 2:
{code}
// Encapsulate with statically imported helper method that catches exceptions 
and ignores them, if the passed parameter is true
execWithOptionalIgnoreErrors(ignoreErrorsQ) {
  final x = dangerousOperation() 
  if(x == 1) { return } // return from the enclosing method
  // Note: break & continue are not allowed here
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GROOVY-8301) break/return/continue support in "Appended Block Closures"

2017-08-27 Thread mg (JIRA) 
mg created GROOVY-8301:
--

 Summary: break/return/continue support in "Appended Block Closures"
 Key: GROOVY-8301
 URL: https://issues.apache.org/jira/browse/GROOVY-8301
 Project: Groovy
  Issue Type: Proposal
  Components: Compiler
Reporter: mg


This proposal revisits the idea to change the semantics of the break, return, 
and continue keyword for closures that are used in a way that mimics Java block 
constructs such as if, for, or while.

Example 1:
{code}
// Iterate over all PERSON rows in the result set
sqe.forEachRow("select * from PERSON") { final row ->
  if(row.TAG == 0) { break } // Leave forEachRow loop
  if(row.TAG == 1) { return } // return from the method enclosing the 
forEachRow loop
  if(row.TAG == 2) { continue } // Move to next iteration in the forEachRow loop
}
{code}


Example 2:
{code}
// Encapsulate with statically imported helper method that catches exceptions 
and ignores them, if the passed parameter is true
execWithOptionalIgnoreErrors(ignoreErrorsQ) {
  final x = dangerousOperation() 
  if(x == 1) { return } // return from the enclosing method
  // Note: break & continue are not allowed here
}
{code}



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Updated] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread Paul King (JIRA) 

 [ 
https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King updated GROOVY-8300:
--
Description: 
When defined on a method or constructor, all parameters of that 
method/constructor will be final. When applied on a class, the annotation 
applies to all methods/constructors.

Still to be determined:
# Should visibility matter, e.g. would it apply to all public, protected, 
private, etc. members, or does there need to be some ability to customise?
# Should the annotation apply to fields/properties? Applying 'final' to a 
field/property seems to be more efficient than applying @AutoFinal but would 
there ever be a desire to apply such an annotation to all fields/properties?

  was:
When defined on a method or constructor, all parameters of that 
method/constructor will be final. When applied on a class, the annotation 
applies to all methods/constructors.

Still to be determined:
# Should visibility matter, e.g. would it all to all public, protected, private 
members, or does there need to be some ability to customise?
# Should the annotation apply to fields/properties? Applying 'final' to a 
field/property seems to be more efficient than applying @AutoFinal but would 
there ever be a desire to apply such an annotation to all fields/properties?


> Groovy should have an @AutoFinal annotation
> ---
>
> Key: GROOVY-8300
> URL: https://issues.apache.org/jira/browse/GROOVY-8300
> Project: Groovy
>  Issue Type: New Feature
>Reporter: Paul King
>
> When defined on a method or constructor, all parameters of that 
> method/constructor will be final. When applied on a class, the annotation 
> applies to all methods/constructors.
> Still to be determined:
> # Should visibility matter, e.g. would it apply to all public, protected, 
> private, etc. members, or does there need to be some ability to customise?
> # Should the annotation apply to fields/properties? Applying 'final' to a 
> field/property seems to be more efficient than applying @AutoFinal but would 
> there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (GROOVY-8300) Groovy should have an @AutoFinal annotation

2017-08-27 Thread Paul King (JIRA) 
Paul King created GROOVY-8300:
-

 Summary: Groovy should have an @AutoFinal annotation
 Key: GROOVY-8300
 URL: https://issues.apache.org/jira/browse/GROOVY-8300
 Project: Groovy
  Issue Type: New Feature
Reporter: Paul King


When defined on a method or constructor, all parameters of that 
method/constructor will be final. When applied on a class, the annotation 
applies to all methods/constructors.

Still to be determined:
# Should visibility matter, e.g. would it all to all public, protected, private 
members, or does there need to be some ability to customise?
# Should the annotation apply to fields/properties? Applying 'final' to a 
field/property seems to be more efficient than applying @AutoFinal but would 
there ever be a desire to apply such an annotation to all fields/properties?



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (GROOVY-8299) Generate bytecode for interface with default and static methods

2017-08-27 Thread Daniel Sun (JIRA) 

[ 
https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16143032#comment-16143032
 ] 

Daniel Sun commented on GROOVY-8299:


If bytecode version > 1.6, IndyStaticTypesMultiTypeDispatcher will be used...

https://github.com/apache/groovy/blob/master/src/main/org/codehaus/groovy/classgen/asm/sc/StaticTypesWriterController.java#L65-L67

But in the 
org.codehaus.groovy.classgen.asm.sc.StaticCompilationTest#testArrayGet, we use 
config.optimizationOptions.indy to check if indy enabled...

So when we set 1.8 as default bytecode version, some tests fails...

OMG...

> Generate bytecode for interface with default and static methods
> ---
>
> Key: GROOVY-8299
> URL: https://issues.apache.org/jira/browse/GROOVY-8299
> Project: Groovy
>  Issue Type: Improvement
>  Components: Compiler
>Affects Versions: 3.0.0-alpha-1, 2.6.0-alpha-1
>Reporter: Daniel Sun
>Assignee: Daniel Sun
>
> Currently the interface with default methods is based on the traits, we 
> should provide real default methods introduced by Java8.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)