[jira] [Updated] (GROOVY-7569) PowerAsserts should print results more verbosely and safer
[ 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
[ 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
[ 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
[ https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ 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
[ https://issues.apache.org/jira/browse/GROOVY-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
[ https://issues.apache.org/jira/browse/GROOVY-8303?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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...
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
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
[ https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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
[ https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] [Commented] (GROOVY-8300) Groovy should have an @AutoFinal annotation
[ https://issues.apache.org/jira/browse/GROOVY-8300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16143159#comment-16143159 ] mg commented on GROOVY-8300: My main rationale for suggesting this feature was for _final parameters_, i.e. having the easier to read / less cluttered {code} foo(String name, boolean trimQ, boolean indentLinesQ, boolean keepEmptyLinesIndentationQ, boolean seperateFunctionsQ, boolean uppercaseKeywordsQ, boolean uppercaseNamesQ) { } {code} instead of {code} foo(final String name, final boolean trimQ, final boolean final indentLinesQ, final boolean keepEmptyLinesIndentationQ, final boolean seperateFunctionsQ, final boolean uppercaseKeywordsQ, final boolean uppercaseNamesQ) { } {code} in my code everywhere, while still # being sure that all parameters could not be reassigned in the method body, and # potentially allowing the compiler to optimize the code accordingly (Note: According to [~blackdrag], no such optimizations are currently applied). > 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
[ 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
[ 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"
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"
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
[ 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
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
[ https://issues.apache.org/jira/browse/GROOVY-8299?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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)