[jira] [Commented] (GROOVY-8376) Add @DelegatesTo to SwingBuilder methods that call setDelegate
[
https://issues.apache.org/jira/browse/GROOVY-8376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16246642#comment-16246642
]
Eric Milles commented on GROOVY-8376:
-
And {{edtBuilder}}, which calls {{edt}} in turn.
> Add @DelegatesTo to SwingBuilder methods that call setDelegate
> --
>
> Key: GROOVY-8376
> URL: https://issues.apache.org/jira/browse/GROOVY-8376
> Project: Groovy
> Issue Type: Improvement
>Reporter: Eric Milles
>
> 4 mehtods in SwingBuilder (edt, doLater, doOutside, build) call
> setDelegate(this) on their closure params. Could each have the param
> annotated with {{@DelegatesTo(SwingBuilder)}}?
> Ex:
> {code}
> public Object build(@DelegatesTo(SwingBuilder) Closure c) {
> c.setDelegate(this)
> return c.call()
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8376) Add @DelegatesTo to SwingBuilder methods that call setDelegate
Eric Milles created GROOVY-8376:
---
Summary: Add @DelegatesTo to SwingBuilder methods that call
setDelegate
Key: GROOVY-8376
URL: https://issues.apache.org/jira/browse/GROOVY-8376
Project: Groovy
Issue Type: Improvement
Reporter: Eric Milles
4 mehtods in SwingBuilder (edt, doLater, doOutside, build) call
setDelegate(this) on their closure params. Could each have the param annotated
with {{@DelegatesTo(SwingBuilder)}}?
Ex:
{code}
public Object build(@DelegatesTo(SwingBuilder) Closure c) {
c.setDelegate(this)
return c.call()
}
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-8375) Closure resolve strategy DELEGATE_FIRST and DELEGATE_ONLY behave oddly when delegate is set
[
https://issues.apache.org/jira/browse/GROOVY-8375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-8375:
Description:
The sample below outputs "value" as is. When {{cl.resolveStrategy =
Closure.DELEGATE_FIRST}} is added before {{cl()}}, it outputs "null" when I
would expect "value" since that's available from owner. When
{{cl.resolveStrategy = Closure.DELEGATE_ONLY}} is added instead, it outputs
"null" when I would expect a missing property exception.
{code}
class Test {
def prop = 'value'
def meth() {
def cl = { -> println prop }
cl.delegate = [:]
cl()
}
}
new Test().meth()
{code}
This was run using Groovy Web Console.
was:
The sample below outputs "value" as is. When {cl.resolveStrategy =
Closure.DELEGATE_FIRST} is added before {cl()}, it outputs {null} when I would
expect {value} since that's available from owner. When {cl.resolveStrategy =
Closure.DELEGATE_ONLY} is added instead, it outputs {null} when I would expect
missing property exception.
{code}
class Test {
def prop = 'value'
def meth() {
def cl = { -> println prop }
cl.delegate = [:]
cl()
}
}
new Test().meth()
{code}
This was run using Groovy Web Console.
> Closure resolve strategy DELEGATE_FIRST and DELEGATE_ONLY behave oddly when
> delegate is set
> ---
>
> Key: GROOVY-8375
> URL: https://issues.apache.org/jira/browse/GROOVY-8375
> Project: Groovy
> Issue Type: Bug
>Reporter: Eric Milles
>
> The sample below outputs "value" as is. When {{cl.resolveStrategy =
> Closure.DELEGATE_FIRST}} is added before {{cl()}}, it outputs "null" when I
> would expect "value" since that's available from owner. When
> {{cl.resolveStrategy = Closure.DELEGATE_ONLY}} is added instead, it outputs
> "null" when I would expect a missing property exception.
> {code}
> class Test {
> def prop = 'value'
> def meth() {
> def cl = { -> println prop }
> cl.delegate = [:]
> cl()
> }
> }
> new Test().meth()
> {code}
> This was run using Groovy Web Console.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (GROOVY-8375) Closure resolve strategy DELEGATE_FIRST and DELEGATE_ONLY behave oddly when delegate is set
Eric Milles created GROOVY-8375:
---
Summary: Closure resolve strategy DELEGATE_FIRST and DELEGATE_ONLY
behave oddly when delegate is set
Key: GROOVY-8375
URL: https://issues.apache.org/jira/browse/GROOVY-8375
Project: Groovy
Issue Type: Bug
Reporter: Eric Milles
The sample below outputs "value" as is. When {cl.resolveStrategy =
Closure.DELEGATE_FIRST} is added before {cl()}, it outputs {null} when I would
expect {value} since that's available from owner. When {cl.resolveStrategy =
Closure.DELEGATE_ONLY} is added instead, it outputs {null} when I would expect
missing property exception.
{code}
class Test {
def prop = 'value'
def meth() {
def cl = { -> println prop }
cl.delegate = [:]
cl()
}
}
new Test().meth()
{code}
This was run using Groovy Web Console.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[GitHub] groovy pull request #631: Android: Remove Invoke Dynamic Call
Github user AndrewReitz commented on a diff in the pull request:
https://github.com/apache/groovy/pull/631#discussion_r149974307
--- Diff: gradle/assemble.gradle ---
@@ -247,6 +247,7 @@ allprojects {
if (isRootProject) {
zipfileset(src:
rootProject.configurations.runtime.files.find { it.name.startsWith('openbeans')
}, excludes: 'META-INF/*')
}
+zap pattern:
'org.codehaus.groovy.vmplugin.v7.IndyInterface'
--- End diff --
What do you think about having two android jars one without classes that
use invoke dynamic and one with them still?
It looks like Android will be supporting it on ap's 26+. The issue is that
Google added a check for classes using the invoke-polymorphic. Little more info
here. https://issuetracker.google.com/issues/37567710
I am able to use proguard to remove the classes that cause the failure, but
it increases build times greatly.
---
[jira] [Comment Edited] (GROOVY-7956) Allow @DelegatesTo on named arguments
[
https://issues.apache.org/jira/browse/GROOVY-7956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15865747#comment-15865747
]
Daniil Ovchinnikov edited comment on GROOVY-7956 at 11/9/17 12:32 PM:
--
EDIT: I don't think this is the best solution, but I leave this comment for
history.
I vote for:
{code}@MapDescription(value = Point, required=['x'])
void methodDescribed(Map point) {
println "$p.x, $p.y"
}
// with ability to annotate parameters
void methodDescribed2(someParameter, @MapDescription(Point) Map point) {
println "$p.x, $p.y"
}
{code}
The second allows such calls to be checked: {{methodDescribed2(42, \[x: 1, y:
2])}}
If {{required}} is empty then all properties should be considered required.
was (Author: daniilo):
I vote for:
{code}@MapDescription(value = Point, required=['x'])
void methodDescribed(Map point) {
println "$p.x, $p.y"
}
// with ability to annotate parameters
void methodDescribed2(someParameter, @MapDescription(Point) Map point) {
println "$p.x, $p.y"
}
{code}
The second allows such calls to be checked: {{methodDescribed2(42, \[x: 1, y:
2])}}
If {{required}} is empty then all properties should be considered required.
> Allow @DelegatesTo on named arguments
> -
>
> Key: GROOVY-7956
> URL: https://issues.apache.org/jira/browse/GROOVY-7956
> Project: Groovy
> Issue Type: New Feature
> Components: GEP
>Reporter: Graeme Rocher
>
> In order to aid static compilation for builders we have {{@DelegatesTo}}
> which allows statically compiled code to know what the delegate of a closure
> is.
> This proposal is to allow {{@DelegatesTo}} on {{Map}} types such that IDEs
> and the static compiler can resolve the target type the named arguments are
> to be used on.
> For example:
> {code}
> class Farm {
> void animal(@DelegatesTo(Animal) Map arguments,
> @DelegatesTo(AnimalBuilder) Closure callable) {
> def animal = new Animal(arguments)
> // handle closure
> }
> }
> class Animal { String name }
> {code}
> The following code would then fail to compile :
> {code}
> def farm = new Farm()
> // compilation failure, no name property on Animal
> farm.animal(nam: "Dog") {
> }
> {code}
> It would then be down to IDEs to also provide support for code completion etc.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (GROOVY-7315) CompileStatic/TypeChecked cannot create non-static nested inner class using named-arg short-hand syntax
[
https://issues.apache.org/jira/browse/GROOVY-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16245529#comment-16245529
]
Paul King commented on GROOVY-7315:
---
Workaround:
{code}
Y makeY() {
//new Y(a:1)
def y = new Y()
y.a = 1
y
}
{code}
> CompileStatic/TypeChecked cannot create non-static nested inner class using
> named-arg short-hand syntax
> ---
>
> Key: GROOVY-7315
> URL: https://issues.apache.org/jira/browse/GROOVY-7315
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.3.9, 2.4.1
>Reporter: Jason Winnebeck
>
> {code}
> @groovy.transform.CompileStatic
> class X {
> Y makeY() {
> new Y(a:1)
> }
>
> private class Y {
> int a
> }
> }
> println new X().makeY()
> {code}
> Error:
> {noformat}
> [Static type checking] - Cannot find matching method X$Y#(X,
> java.util.LinkedHashMap ). Please check
> if the declared type is right and if the method exists.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (GROOVY-7315) CompileStatic/TypeChecked cannot create non-static nested inner class using named-arg short-hand syntax
[
https://issues.apache.org/jira/browse/GROOVY-7315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-7315:
--
Summary: CompileStatic/TypeChecked cannot create non-static nested inner
class using named-arg short-hand syntax (was: CompileStatic/TypeChecked cannot
create non-static nested inner class)
> CompileStatic/TypeChecked cannot create non-static nested inner class using
> named-arg short-hand syntax
> ---
>
> Key: GROOVY-7315
> URL: https://issues.apache.org/jira/browse/GROOVY-7315
> Project: Groovy
> Issue Type: Bug
> Components: Static Type Checker
>Affects Versions: 2.3.9, 2.4.1
>Reporter: Jason Winnebeck
>
> {code}
> @groovy.transform.CompileStatic
> class X {
> Y makeY() {
> new Y(a:1)
> }
>
> private class Y {
> int a
> }
> }
> println new X().makeY()
> {code}
> Error:
> {noformat}
> [Static type checking] - Cannot find matching method X$Y#(X,
> java.util.LinkedHashMap ). Please check
> if the declared type is right and if the method exists.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
