[jira] [Created] (GROOVY-8344) ASTTransformationVisitor should throw early on null ASTTransformation entries
mg created GROOVY-8344:
--
Summary: ASTTransformationVisitor should throw early on null
ASTTransformation entries
Key: GROOVY-8344
URL: https://issues.apache.org/jira/browse/GROOVY-8344
Project: Groovy
Issue Type: Bug
Components: Compiler
Affects Versions: 2.5.0-beta-2
Reporter: mg
Priority: Minor
Conditions under which the error occurs:
# ASTTransformation which does not reside in the org.codehaus.groovy.transform
package (but instead e.g. in org.codehaus.groovy.transform.autofinal)
# ASTTransformation implementation uses an ASTTransformationVisitor
# => NullPointerException when the ASTTransformation is to be applied to
ASTNode|s
in ASTTransformationVisitor#visitClass(ClassNode classNode)
{code}
// second pass, call visit on all of the collected nodes
for (ASTNode[] node : targetNodes) {
for (ASTTransformation snt : transforms.get(node[0])) {
//
snt.visit(node, source); // NullPointerException
}
}
{code}
Stacktrace:
{code}
BUG! exception in phase 'semantic analysis' in source unit
'TestScriptnull2.groovy' unexpected NullpointerException
at
org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:1075)
at
org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:613)
at
org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:591)
at
org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:568)
at
groovy.lang.GroovyClassLoader.doParseClass(GroovyClassLoader.java:299)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:269)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:255)
at groovy.lang.GroovyClassLoader.parseClass(GroovyClassLoader.java:212)
at groovy.lang.GroovyClassLoader$parseClass.call(Unknown Source)
at
gls.CompilableTestSupport.shouldNotCompile(CompilableTestSupport.groovy:27)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite$PogoCachedMethodSiteNoUnwrapNoCoerce.invoke(PogoMetaMethodSite.java:210)
at
org.codehaus.groovy.runtime.callsite.PogoMetaMethodSite.callCurrent(PogoMetaMethodSite.java:59)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:166)
at
org.codehaus.groovy.transform.AutoFinalClosureTransformTest.assertAutoFinalTestScriptWithAnnotation(AutoFinalClosureTransformTest.groovy:217)
at
org.codehaus.groovy.transform.AutoFinalClosureTransformTest$assertAutoFinalTestScriptWithAnnotation$0.callCurrent(Unknown
Source)
at
org.codehaus.groovy.transform.AutoFinalClosureTransformTest.assertAutoFinalClassTestScript(AutoFinalClosureTransformTest.groovy:211)
at
org.codehaus.groovy.transform.AutoFinalClosureTransformTest$assertAutoFinalClassTestScript.callCurrent(Unknown
Source)
at
org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCallCurrent(CallSiteArray.java:52)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:154)
at
org.codehaus.groovy.runtime.callsite.AbstractCallSite.callCurrent(AbstractCallSite.java:174)
at
org.codehaus.groovy.transform.AutoFinalClosureTransformTest.testAutoFinalClosure(AutoFinalClosureTransformTest.groovy:177)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:483)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
[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=16147558#comment-16147558 ] mg commented on GROOVY-8300: Hi Paul, while programming at work, I thought of something we might have overlooked: Are we handling closure arguments right now ?-) Closures become classes afaik, so we would get them if 1) the closure class' methods already exist in the AST at this point, and 2) they are not "synthetic"... Cheers,Markus > 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 >Assignee: 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? *Current thinking*: Don't apply to synthetic > methods unless we find special cases were it is needed. > # What phase should this run at? It needs to be before the (incubating) final > variable analyser is run. *Current thinking*: SEMANTIC_ANALYSIS > # We should have tests to confirm that there are no adverse interactions with > other language features, e.g. default parameter values. *Note*: we should > have a test case that covers this. -- 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=16144530#comment-16144530 ] mg edited comment on GROOVY-8300 at 8/28/17 11:25 PM: -- @What phase should this run at: As early as possible ? Without being any kind of expert in language development, it seems to me that treating this like a C/C++ macro change to the code minimizes any chance of adverse interactions with other language feature... was (Author: emge): @What phase should this run at: As early as possible ? > 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] [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=16144530#comment-16144530 ] mg commented on GROOVY-8300: @What phase should this run at: As early as possible ? > 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] [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=16144525#comment-16144525 ] mg commented on GROOVY-8300: @synthetic methods/constructors: # Can we be sure that the synthetic code does not want to modify its parameters ? # Shouldn't the implementer of the synthetic code generator decide whether to use final or not ? # I think it is not worth the risk of introducing incompatibilities between (future) synthetic code parts and @AutoFinal > 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] [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=16144312#comment-16144312 ] mg commented on GROOVY-8300: I see your side. As as you said, we probably will never have the first two options (includeFields/includeProperties), and right now I also cannot see the 3rd and 4th (includeMethods/includeConstructors). But this is the way other Groovy annotations have been done - and the includeMethodParams/includeConstructorParams parameters also should make it clear that this annotation currently refers only to parameters. > 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] [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=16143515#comment-16143515 ] mg commented on GROOVY-8300: I would strongely argue to change the name to e.g. @AutoFinalParams because of # least surprise: Reading @AutoFinal I would assume it applies to fields etc too # Applying this annotation to specific classes only would imho be confusing; but if it is applied to the whole project, the length of the annotation name should not matter # Potentially adding e.g. @AutoFinalFields in the future would make @AutoFinal even more confusing > 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] [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=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=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=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
[ 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] [Commented] (GROOVY-8258) Create a LINQ-like DSL
[
https://issues.apache.org/jira/browse/GROOVY-8258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16137421#comment-16137421
]
mg commented on GROOVY-8258:
Hi Daniel, back when I did .NET development, creating a LINQ provider used to
be a non-trivial task, so if you have not seen this, maybe it might be
interesting to have a look at their approach:
# https://relinq.codeplex.com/
#
https://www.codeproject.com/Articles/42059/re-linq-ishing-the-Pain-Using-re-linq-to-Implement
> Create a LINQ-like DSL
> --
>
> Key: GROOVY-8258
> URL: https://issues.apache.org/jira/browse/GROOVY-8258
> Project: Groovy
> Issue Type: Improvement
>Reporter: Daniel Sun
>
> *Pojos:*
> {code:java}
> class Category {
>String name
>List articles
> }
> class Article {
> String name
> Integer voteCount
> String categoryName
> }
> {code}
> *Example1:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of articles on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example2:*
> {code:java}
> linq { // return an Iterator>
> from c of categories
> join a of {
> from tempA of articles
> where tempA.voteCount > 10
> select tempA
> } on a.categoryName == c.name // join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> limit 100 offset 50 // pagination
> select { // create a map, its keys: articleName, voteNum, categoryName
> articleName = a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *Example3:*
> {code:java}
> linq { // return an Iterator
> from c of categories
> from a of c.articles // another join
> where c.name == 'Groovy'
> orderBy a.voteCount desc // order by
> select Article { // create an Article instance
> a.name
> a.voteCount
> categoryName = c.name
> }
> }
> {code}
> *TO BE CONTINUED...*
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
