[jira] [Comment Edited] (GROOVY-10714) STC: Callable, Runnable, Serializable overload preference for functional argument (closure, lambda, etc.)
[
https://issues.apache.org/jira/browse/GROOVY-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780030#comment-17780030
]
Eric Milles edited comment on GROOVY-10714 at 1/16/24 10:45 PM:
GROOVY-6189 links to GEP-12, which specifically mentions that types implemented
by {{Closure}} represent a coercion-free match and so are preferred over
SAM-type overloads.
For reference, the distance computed between {{Closure}} and several
interesting types are currently as follows:
||Type||Argument-Parameter Distance||
|Closure|0|
|Cloneable|1|
|Serializable|1|
|GroovyCallable|1|
|Callable|2|
|Runnable|1|
|GroovyObject|1|
|GroovyObjectSupport|4|
|Object|14|
|SAM-type|13
or 12 (if param count helps; GROOVY-9881)
or 15 (if param count hurts; GROOVY-11121)|
was (Author: emilles):
GROOVY-6189 links to GEP-12, which specifically mentions that types implemented
by {{Closure}} represent a coercion-free match and so are preferred over
SAM-type overloads.
For reference, the distance computed between {{Closure}} and several
interesting types are currently as follows:
||Type||Argument-Parameter Distance||
|Closure|0|
|Cloneable|1|
|Serializable|1|
|GroovyCallable|1|
|Callable|2|
|Runnable|1|
|GroovyObject|1|
|GroovyObjectSupport|4|
|Object|14|
|SAM-type|13 or 12 (if param count helps) or
15 (if param count hurts; GROOVY-11121)|
> STC: Callable, Runnable, Serializable overload preference for functional
> argument (closure, lambda, etc.)
> -
>
> Key: GROOVY-10714
> URL: https://issues.apache.org/jira/browse/GROOVY-10714
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 4.0.4
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> This appears to be similar to GROOVY-9881, but it's specifically in the
> method-overload procedure. Given a functional value type with two method
> overloads:
> {code}
> interface Try {
> Try andThenTry(Consumer)
> Try andThenTry(Runnable)
> }
> {code}
> When this code is invoked from static code, the STC errors out on an
> ambiguous method reference even if the method type isn't:
> {code}
> // AWS SDK 2 DynamoDbTable
> class DynamoDbTable {
> void putItem(PutItemRequest)
> void putItem(Consumer)
> void putItem(T)
> }
> @CompileStatic
> class MyServiceClass {
> void doThing() {
> Try.success(putItemRequest())
> .andThenTry(table::putItem) // T for Try is PutItemRequest
> }
> }
> {code}
> produces
> {code}
> [Static type checking] - Reference to method is ambiguous. Cannot choose
> between [Try Try#andThenTry(Consumer), Try
> Try#andThenTry(Runnable)]
> {code}
> I think this may have something to do with the relaxed SAM matching that is
> used to bridge ambiguous closure syntax, but when a plain method reference is
> used, there's no ambiguity available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10714) STC: Callable, Runnable, Serializable overload preference for functional argument (closure, lambda, etc.)
[
https://issues.apache.org/jira/browse/GROOVY-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17780030#comment-17780030
]
Eric Milles edited comment on GROOVY-10714 at 1/16/24 4:20 PM:
---
GROOVY-6189 links to GEP-12, which specifically mentions that types implemented
by {{Closure}} represent a coercion-free match and so are preferred over
SAM-type overloads.
For reference, the distance computed between {{Closure}} and several
interesting types are currently as follows:
||Type||Argument-Parameter Distance||
|Closure|0|
|Cloneable|1|
|Serializable|1|
|GroovyCallable|1|
|Callable|2|
|Runnable|1|
|GroovyObject|1|
|GroovyObjectSupport|4|
|Object|14|
|SAM-type|13 or 12 (if param count helps) or
15 (if param count hurts; GROOVY-11121)|
was (Author: emilles):
GROOVY-6189 links to GEP-12, which specifically mentions that types implemented
by {{Closure}} represent a coercion-free match and so are preferred over
SAM-type overloads.
For reference, the distance computed between {{Closure}} and several
interesting types are currently as follows:
||Type||Argument-Parameter Distance||
|Closure|0|
|Cloneable|1|
|Serializable|1|
|GroovyCallable|1|
|Callable|2|
|Runnable|1|
|GroovyObject|1|
|GroovyObjectSupport|4|
|Object|14|
|SAM-type|13 or 12 (if param count helps)|
> STC: Callable, Runnable, Serializable overload preference for functional
> argument (closure, lambda, etc.)
> -
>
> Key: GROOVY-10714
> URL: https://issues.apache.org/jira/browse/GROOVY-10714
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 4.0.4
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> This appears to be similar to GROOVY-9881, but it's specifically in the
> method-overload procedure. Given a functional value type with two method
> overloads:
> {code}
> interface Try {
> Try andThenTry(Consumer)
> Try andThenTry(Runnable)
> }
> {code}
> When this code is invoked from static code, the STC errors out on an
> ambiguous method reference even if the method type isn't:
> {code}
> // AWS SDK 2 DynamoDbTable
> class DynamoDbTable {
> void putItem(PutItemRequest)
> void putItem(Consumer)
> void putItem(T)
> }
> @CompileStatic
> class MyServiceClass {
> void doThing() {
> Try.success(putItemRequest())
> .andThenTry(table::putItem) // T for Try is PutItemRequest
> }
> }
> {code}
> produces
> {code}
> [Static type checking] - Reference to method is ambiguous. Cannot choose
> between [Try Try#andThenTry(Consumer), Try
> Try#andThenTry(Runnable)]
> {code}
> I think this may have something to do with the relaxed SAM matching that is
> used to bridge ambiguous closure syntax, but when a plain method reference is
> used, there's no ambiguity available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10714) STC: Callable, Runnable, Serializable overload preference for functional argument (closure, lambda, etc.)
[
https://issues.apache.org/jira/browse/GROOVY-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574283#comment-17574283
]
Eric Milles edited comment on GROOVY-10714 at 1/16/24 3:04 AM:
---
There are a couple of things at play here. When looking at a method call, the
type checker first visits the arguments to determine the types to use for
method selection. For the method reference "table::putItem" this means checking
for the methods "putItem" from your table type. At this point,
{{Closure}} is used as the type. Under STC not SC, a method
reference produces a {{{}MethodClosure{}}}.
Next, the method "andThenTry" is looked up using the argument types. In this
case, "andThenTry(Consumer)" and "andThenTry(Runnable)". To select from
multiple options, a distance calculation is made. Since {{Closure}} actually
implements {{{}Runnable{}}}, it is deemed much closer than {{{}Consumer{}}}.
I'm not sure why you are seeing ambiguous method error when I am getting method
selected unambiguously but then reference fails type-checking.
It is not until after selecting the target method that parameter types can be
used to clarify argument types.
was (Author: emilles):
There are a couple of things at play here. When looking at a method call, the
type checker first visits the arguments to determine the types to use for
method selection. For the method reference "table::putItem" this means checking
for the methods "putItem" from your table type. At this point,
{{Closure}} is used as the type. Under STC not SC, a method
reference produces a {{{}MethodClosure{}}}.
Next, the method "andThenTry" is looked up using the argument types. In this
case, "andThenTry(Consumer)" and "andThenTry(Runnable)". To select from
multiple options, a distance calculation is made. Since {{Closure}} actually
implements {{{}Runnable{}}}, it is deemed much closer than {{{}Consumer{}}}.
I'm not sure why you are seeing smbiguous method error when I am getting method
selected unambiguously but then reference fails type-checking.
It is not until after selecting the target method that parameter types can be
used to clarify argument types.
> STC: Callable, Runnable, Serializable overload preference for functional
> argument (closure, lambda, etc.)
> -
>
> Key: GROOVY-10714
> URL: https://issues.apache.org/jira/browse/GROOVY-10714
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 4.0.4
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Major
>
> This appears to be similar to GROOVY-9881, but it's specifically in the
> method-overload procedure. Given a functional value type with two method
> overloads:
> {code}
> interface Try {
> Try andThenTry(Consumer)
> Try andThenTry(Runnable)
> }
> {code}
> When this code is invoked from static code, the STC errors out on an
> ambiguous method reference even if the method type isn't:
> {code}
> // AWS SDK 2 DynamoDbTable
> class DynamoDbTable {
> void putItem(PutItemRequest)
> void putItem(Consumer)
> void putItem(T)
> }
> @CompileStatic
> class MyServiceClass {
> void doThing() {
> Try.success(putItemRequest())
> .andThenTry(table::putItem) // T for Try is PutItemRequest
> }
> }
> {code}
> produces
> {code}
> [Static type checking] - Reference to method is ambiguous. Cannot choose
> between [Try Try#andThenTry(Consumer), Try
> Try#andThenTry(Runnable)]
> {code}
> I think this may have something to do with the relaxed SAM matching that is
> used to bridge ambiguous closure syntax, but when a plain method reference is
> used, there's no ambiguity available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10714) STC: Callable, Runnable, Serializable overload preference for functional argument (closure, lambda, etc.)
[
https://issues.apache.org/jira/browse/GROOVY-10714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17574283#comment-17574283
]
Eric Milles edited comment on GROOVY-10714 at 12/7/22 2:54 PM:
---
There are a couple of things at play here. When looking at a method call, the
type checker first visits the arguments to determine the types to use for
method selection. For the method reference "table::putItem" this means checking
for the methods "putItem" from your table type. At this point,
{{Closure}} is used as the type. Under STC not SC, a method
reference produces a {{{}MethodClosure{}}}.
Next, the method "andThenTry" is looked up using the argument types. In this
case, "andThenTry(Consumer)" and "andThenTry(Runnable)". To select from
multiple options, a distance calculation is made. Since {{Closure}} actually
implements {{{}Runnable{}}}, it is deemed much closer than {{{}Consumer{}}}.
I'm not sure why you are seeing smbiguous method error when I am getting method
selected unambiguously but then reference fails type-checking.
It is not until after selecting the target method that parameter types can be
used to clarify argument types.
was (Author: emilles):
There are a couple of thing at play here. When looking at a method call, the
type checker first visits the arguments to determine the types to use for
method selection. For the method reference "table::putItem" this means
checking for the methods "putItem" from your table type. At this point,
{{Closure}} is used as the type. Under STC not SC, a method
reference produces a {{MethodClosure}}.
Next, the method "andThenTry" is looked up using the argument types. In this
case, "andThenTry(Consumer)" and "andThenTry(Runnable)". To select from
multiple options, a distance calculation is made. Since {{Closure}} actually
implements {{Runnable}}, it is deemed much closer than {{Consumer}}. I'm not
sure why you are seeing smbiguous method error when I am getting method
selected unambiguously but then reference fails type-checking.
It is not until after selecting the target method that parameter types can be
used to clarify argument types.
> STC: Callable, Runnable, Serializable overload preference for functional
> argument (closure, lambda, etc.)
> -
>
> Key: GROOVY-10714
> URL: https://issues.apache.org/jira/browse/GROOVY-10714
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation
>Affects Versions: 4.0.4
>Reporter: Christopher Smith
>Assignee: Eric Milles
>Priority: Minor
>
> This appears to be similar to GROOVY-9881, but it's specifically in the
> method-overload procedure. Given a functional value type with two method
> overloads:
> {code}
> interface Try {
> Try andThenTry(Consumer)
> Try andThenTry(Runnable)
> }
> {code}
> When this code is invoked from static code, the STC errors out on an
> ambiguous method reference even if the method type isn't:
> {code}
> // AWS SDK 2 DynamoDbTable
> class DynamoDbTable {
> void putItem(PutItemRequest)
> void putItem(Consumer)
> void putItem(T)
> }
> @CompileStatic
> class MyServiceClass {
> void doThing() {
> Try.success(putItemRequest())
> .andThenTry(table::putItem) // T for Try is PutItemRequest
> }
> }
> {code}
> produces
> {code}
> [Static type checking] - Reference to method is ambiguous. Cannot choose
> between [Try Try#andThenTry(Consumer), Try
> Try#andThenTry(Runnable)]
> {code}
> I think this may have something to do with the relaxed SAM matching that is
> used to bridge ambiguous closure syntax, but when a plain method reference is
> used, there's no ambiguity available.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
