[jira] [Commented] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582677#comment-17582677
]
ASF GitHub Bot commented on GROOVY-8788:
eric-milles closed pull request #1766: GROOVY-8788: STC: prefer closer
parameter match over self-type match
URL: https://github.com/apache/groovy/pull/1766
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [groovy] eric-milles closed pull request #1766: GROOVY-8788: STC: prefer closer parameter match over self-type match
eric-milles closed pull request #1766: GROOVY-8788: STC: prefer closer parameter match over self-type match URL: https://github.com/apache/groovy/pull/1766 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582672#comment-17582672
]
ASF GitHub Bot commented on GROOVY-8788:
eric-milles opened a new pull request, #1768:
URL: https://github.com/apache/groovy/pull/1768
Given choice between methods m(String,Object) and m(Object,String), prefer
closer parameter matching. This aligns with the method selection of the dynamic
runtime. There is much more discussion of the various test cases in the ticket.
With proper selection of `getAt(Object,String)` over `getAt(Map,Object)` and
`putAt(Object,String,Object)` over `putAt(Map,K,V)` there are quite a few STC
test issues. Not sure if I should separate them out to a test script just for
8788 or mitigate them with some minor changes or something else. I'd be
interested to hear how this sits now. @blackdrag @paulk-asert
https://issues.apache.org/jira/browse/GROOVY-8788
https://issues.apache.org/jira/browse/GROOVY-6504
https://issues.apache.org/jira/browse/GROOVY-6849
https://issues.apache.org/jira/browse/GROOVY-6970
https://issues.apache.org/jira/browse/GROOVY-8787
https://issues.apache.org/jira/browse/GROOVY-9069
https://issues.apache.org/jira/browse/GROOVY-9420
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [groovy] eric-milles opened a new pull request, #1768: GROOVY-8788: STC: prefer closer parameter match over receiver-type match
eric-milles opened a new pull request, #1768: URL: https://github.com/apache/groovy/pull/1768 Given choice between methods m(String,Object) and m(Object,String), prefer closer parameter matching. This aligns with the method selection of the dynamic runtime. There is much more discussion of the various test cases in the ticket. With proper selection of `getAt(Object,String)` over `getAt(Map,Object)` and `putAt(Object,String,Object)` over `putAt(Map,K,V)` there are quite a few STC test issues. Not sure if I should separate them out to a test script just for 8788 or mitigate them with some minor changes or something else. I'd be interested to hear how this sits now. @blackdrag @paulk-asert https://issues.apache.org/jira/browse/GROOVY-8788 https://issues.apache.org/jira/browse/GROOVY-6504 https://issues.apache.org/jira/browse/GROOVY-6849 https://issues.apache.org/jira/browse/GROOVY-6970 https://issues.apache.org/jira/browse/GROOVY-8787 https://issues.apache.org/jira/browse/GROOVY-9069 https://issues.apache.org/jira/browse/GROOVY-9420 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: notifications-unsubscr...@groovy.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Comment Edited] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582550#comment-17582550
]
Eric Milles edited comment on GROOVY-8788 at 8/21/22 1:32 PM:
--
6. mixed declaration and extension (pt.2)
{code:groovy}
class A { int m(String s) {4} }
class B extends A { }
class C extends B { }
class Ext {
static m(B self, Object o) {2}
}
use (Ext) {
def a = new A()
assert a.m(new String()) == 4
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 4
def c = new C()
assert c.m(new Object()) == 2
assert c.m(new String()) == 4
}
{code}
This case behaves under dynamic and static compilation. So no change required.
:)
*Update:* the commit changes the selection for {{c.m(new String())}}; I am
investigating
was (Author: emilles):
6. mixed declaration and extension (pt.2)
{code:groovy}
class A { int m(String s) {4} }
class B extends A { }
class C extends B { }
class Ext {
static m(B self, Object o) {2}
}
use (Ext) {
def a = new A()
assert a.m(new String()) == 4
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 4
def c = new C()
assert c.m(new Object()) == 2
assert c.m(new String()) == 4
}
{code}
This case behaves under dynamic and static compilation. So no change required.
:)
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582550#comment-17582550
]
Eric Milles commented on GROOVY-8788:
-
6. mixed declaration and extension (pt.2)
{code:groovy}
class A { int m(String s) {4} }
class B extends A { }
class C extends B { }
class Ext {
static m(B self, Object o) {2}
}
use (Ext) {
def a = new A()
assert a.m(new String()) == 4
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 4
def c = new C()
assert c.m(new Object()) == 2
assert c.m(new String()) == 4
}
{code}
This case behaves under dynamic and static compilation. So no change required.
:)
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582543#comment-17582543
]
Eric Milles edited comment on GROOVY-8788 at 8/21/22 12:20 PM:
---
If my understanding of #1-#5 is consistent, this commit does work to fix the
self-type weighting of STC/SC:
https://github.com/apache/groovy/pull/1766/commits/488f8a8f336efae32349317f219a8f8df8994114
I can separate out the getAt change if that helps. There will be some fallout
to having {{getAt(Object,String)}} selected over {{getAt(Map,Object)}} by
the type checker.
And based on all this, I actually noticed that the javadoc assertions for
{{getAt(Map,Object)}} are not even targeting that method. They go to
{{getAt(Object,String)}} because they use string keys.
Further, because {{getAt(Object,String)}} is implemented via getProperty, there
is an edge case where you can extend map and declare a property, which is what
this refers to (edited to reflect current behavior):
{code:groovy}
class HM extends HashMap {
String a = 'x'
}
map = new HM()
map.put("a",1)
assert map["a"] == 'x'
{code}
was (Author: emilles):
If my understanding of #1-#5 is consistent, this commit does work to fix the
self-type weighting of STC/SC:
https://github.com/apache/groovy/pull/1766/commits/488f8a8f336efae32349317f219a8f8df8994114
I can separate out the getAt change if that helps. There will be some fallout
to having {{getAt(Object,String)}} selected over {{getAt(Map,Object)}}.
And based on all this, I actually noticed that the javadoc assertions for
{{getAt(Map,Object)}} are not even targeting that method. They go to
{{getAt(Object,String)}} because they use string keys.
Further, because {{getAt(Object,String)}} is implemented via getProperty, there
is an edge case where you can extend map and declare a property, which is what
this refers to (edited to reflect current behavior):
{code:groovy}
class HM extends HashMap {
String a = 'x'
}
map = new HM()
map.put("a",1)
assert map["a"] == 'x'
{code}
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582543#comment-17582543
]
Eric Milles commented on GROOVY-8788:
-
If my understanding of #1-#5 is consistent, this commit does work to fix the
self-type weighting of STC/SC:
https://github.com/apache/groovy/pull/1766/commits/488f8a8f336efae32349317f219a8f8df8994114
I can separate out the getAt change if that helps. There will be some fallout
to having {{getAt(Object,String)}} selected over {{getAt(Map,Object)}}.
And based on all this, I actually noticed that the javadoc assertions for
{{getAt(Map,Object)}} are not even targeting that method. They go to
{{getAt(Object,String)}} because they use string keys.
Further, because {{getAt(Object,String)}} is implemented via getProperty, there
is an edge case where you can extend map and declare a property, which is what
this refers to (edited to reflect current behavior):
{code:groovy}
class HM extends HashMap {
String a = 'x'
}
map = new HM()
map.put("a",1)
assert map["a"] == 'x'
{code}
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-10726) IntRange#subListBorders gives incorrect values for certain exclusive ranges
[ https://issues.apache.org/jira/browse/GROOVY-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582521#comment-17582521 ] Paul King edited comment on GROOVY-10726 at 8/21/22 11:57 AM: -- False alarm. I had forgotten that we store in RangeInfo "to + 1" so that it can be directly used in e.g. subList. I added some extra tests to make that more obvious. was (Author: paulk): False alarm. I had forgotten that we store in RangeInfo "to + 1" so that it can be directly used in e.g. subList. > IntRange#subListBorders gives incorrect values for certain exclusive ranges > --- > > Key: GROOVY-10726 > URL: https://issues.apache.org/jira/browse/GROOVY-10726 > Project: Groovy > Issue Type: Bug >Reporter: Paul King >Priority: Major > > We add one instead of subtract one for particular cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582540#comment-17582540
]
Eric Milles edited comment on GROOVY-8788 at 8/21/22 11:54 AM:
---
4. overload and override -- I think we all expect {{b.m(new String())}} to
return 3 now and Groovy follows suit
{code:groovy}
class A { }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
static m(B self, String s) {3}
}
use (Cat) {
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 3
}
{code}
5. mixed declaration and extension
{code:groovy}
class A { int m(String s) {4} }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
}
use (Cat) {
def a = new A()
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
}
{code}
Here we have something interesting and new. Groovy chooses extension method
{{m(String)}} over declared method {{m(String)}}. I think this is how {{String
toString(Object self)}} works. Even in this case for {{b.m(new String())}},
the static compiler selects {{m(Object)}} given two {{m(String)}} options.
Further confirmation for me that SC is improperly weighting the self type B.
was (Author: emilles):
4. overload and override -- I think we all expect {{b.m(new String())}} to
return 3 now and Groovy follow suit
{code:groovy}
class A { }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
static m(B self, String s) {3}
}
use (Cat) {
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 3
}
{code}
5. mixed declaration and extension
{code:groovy}
class A { int m(String s) {4} }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
}
use (Cat) {
def a = new A()
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
}
{code}
Here we have something interesting and new. Groovy chooses extension method
{{m(String)}} over declared method {{m(String)}}. I think this is how {{String
toString(Object self)}} works. Even in this case for {{b.m(new String())}},
the static compiler selects {{m(Object)}} given two {{m(String)}} options.
Further confirmation for me that SC is improperly weighting the self type B.
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582540#comment-17582540
]
Eric Milles commented on GROOVY-8788:
-
4. overload and override -- I think we all expect {{b.m(new String())}} to
return 3 now and Groovy follow suit
{code:groovy}
class A { }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
static m(B self, String s) {3}
}
use (Cat) {
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 3
}
{code}
5. mixed declaration and extension
{code:groovy}
class A { int m(String s) {4} }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
}
use (Cat) {
def a = new A()
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
}
{code}
Here we have something interesting and new. Groovy chooses extension method
{{m(String)}} over declared method {{m(String)}}. I think this is how {{String
toString(Object self)}} works. Even in this case for {{b.m(new String())}},
the static compiler selects {{m(Object)}} given two {{m(String)}} options.
Further confirmation for me that SC is improperly weighting the self type B.
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582532#comment-17582532
]
Eric Milles edited comment on GROOVY-8788 at 8/21/22 11:35 AM:
---
Let me see if I can break this down from your examples, with some small edits
of mine.
1. overload is more specific -- nothing surprising here
{code:groovy}
class A {
def m(Object o) {1}
}
class B extends A {
def m(String s) {2}
}
def a = new A()
assert a.m(new Object()) == 1
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 1
assert b.m(new String()) == 2
{code}
2. overload is more general -- selection is based on argument type
{code:groovy}
import static groovy.test.GroovyAssert.shouldFail
class A {
def m(String s) {1}
}
class B extends A {
def m(Object o) {2}
}
def a = new A()
shouldFail(MissingMethodException) { a.m(new Object()) }
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
{code}
3. category/extension overloads -- same behavior as declared methods; OP
expects this behavior
{code:groovy}
class A { }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
}
use (Cat) {
def a = new A()
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
}
{code}
Hopefully nothing surprising so far. #1 and #2 run the same under static
compilation. #3 requires a little more work since {{use}} cannot be used under
static compilation.
Under static compilation, {{b.m(new String())}} returns 2. This is the
inconsistency the OP refers to. Separate from all the map stuff, do you agree
that selection of {{m(Object)}} over {{m(String)}} by the static compiler is
the incorrect choice? [~blackdrag] [~paulk]
Under your second example, you state "m(Object) is to be seen as if it is a
method of B. m(String) is to be seen as if a method of A. Since B extends A and
since B does not define a new m(String), the extension method for A has to be
chosen here" which confirms for me that OP and you and I agree, the static
compiler is selecting the wrong method.
was (Author: emilles):
Let me see if I can break this down from your examples, with some small edits
of mine.
1. overload is more specific -- nothing surprising here
{code:groovy}
class A {
def m(Object o) {1}
}
class B extends A {
def m(String s) {2}
}
def a = new A()
assert a.m(new Object()) == 1
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 1
assert b.m(new String()) == 2
{code}
2. overload is more general -- selection is based on argument type
{code:groovy}
import static groovy.test.GroovyAssert.shouldFail
class A {
def m(String s) {1}
}
class B extends A {
def m(Object o) {2}
}
def a = new A()
shouldFail(MissingMethodException) { a.m(new Object()) }
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
{code}
3. category/extension overloads -- same behavior as declared methods; OP
expects this behavior
{code:groovy}
class A { }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
}
use (Cat) {
def a = new A()
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
}
{code}
Hopefully nothing surprising so far. #1 and #2 run the same under static
compilation. #3 requires a little more work since {{use}} cannot be used under
static compilation.
Under static compilation, {{b.m(new String())}} returns 2. This is the
inconsistency the OP refers to. Separate from all the map stuff, do you agree
that selection of {{m(Object)}} over {{m(String)}} by the static compiler is
the incorrect choice? [~blackdrag] [~paulk]
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void u
[jira] [Comment Edited] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582532#comment-17582532
]
Eric Milles edited comment on GROOVY-8788 at 8/21/22 11:31 AM:
---
Let me see if I can break this down from your examples, with some small edits
of mine.
1. overload is more specific -- nothing surprising here
{code:groovy}
class A {
def m(Object o) {1}
}
class B extends A {
def m(String s) {2}
}
def a = new A()
assert a.m(new Object()) == 1
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 1
assert b.m(new String()) == 2
{code}
2. overload is more general -- selection is based on argument type
{code:groovy}
import static groovy.test.GroovyAssert.shouldFail
class A {
def m(String s) {1}
}
class B extends A {
def m(Object o) {2}
}
def a = new A()
shouldFail(MissingMethodException) { a.m(new Object()) }
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
{code}
3. category/extension overloads -- same behavior as declared methods; OP
expects this behavior
{code:groovy}
class A { }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
}
use (Cat) {
def a = new A()
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
}
{code}
Hopefully nothing surprising so far. #1 and #2 run the same under static
compilation. #3 requires a little more work since {{use}} cannot be used under
static compilation.
Under static compilation, {{b.m(new String())}} returns 2. This is the
inconsistency the OP refers to. Separate from all the map stuff, do you agree
that selection of {{m(Object)}} over {{m(String)}} by the static compiler is
the incorrect choice? [~blackdrag] [~paulk]
was (Author: emilles):
Let me see if I can break this down from your examples, with some small edits
of mine.
1. overload is more specific -- nothing surprising here
{code:groovy}
class A {
def m(Object o) {1}
}
class B extends A {
def m(String s) {2}
}
def a = new A()
assert a.m(new Object()) == 1
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 1
assert b.m(new String()) == 2
{code}
2. overload is more general -- selection is based on argument type
{code:groovy}
import static groovy.test.GroovyAssert.shouldFail
class A {
def m(String s) {1}
}
class B extends A {
def m(Object o) {2}
}
def a = new A()
shouldFail(MissingMethodException) { a.m(new Object()) }
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
{code}
3. category/extension overloads -- same behavior as declared methods; OP
expects this behavior
{code:groovy}
class A { }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
}
use (Cat) {
def a = new A()
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
}
{code}
Hopefully nothing surprising so far. #1 and #2 run the same under static
compilation. #3 requires a little more work since {{use}} cannot be used under
static compilation.
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (GROOVY-8788) Inconsistency in extension method selection with @CompileStatic
[
https://issues.apache.org/jira/browse/GROOVY-8788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17582532#comment-17582532
]
Eric Milles commented on GROOVY-8788:
-
Let me see if I can break this down from your examples, with some small edits
of mine.
1. overload is more specific -- nothing surprising here
{code:groovy}
class A {
def m(Object o) {1}
}
class B extends A {
def m(String s) {2}
}
def a = new A()
assert a.m(new Object()) == 1
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 1
assert b.m(new String()) == 2
{code}
2. overload is more general -- selection is based on argument type
{code:groovy}
import static groovy.test.GroovyAssert.shouldFail
class A {
def m(String s) {1}
}
class B extends A {
def m(Object o) {2}
}
def a = new A()
shouldFail(MissingMethodException) { a.m(new Object()) }
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
{code}
3. category/extension overloads -- same behavior as declared methods; OP
expects this behavior
{code:groovy}
class A { }
class B extends A { }
class Cat {
static m(A self, String s) {1}
static m(B self, Object o) {2}
}
use (Cat) {
def a = new A()
assert a.m(new String()) == 1
def b = new B()
assert b.m(new Object()) == 2
assert b.m(new String()) == 1
}
{code}
Hopefully nothing surprising so far. #1 and #2 run the same under static
compilation. #3 requires a little more work since {{use}} cannot be used under
static compilation.
> Inconsistency in extension method selection with @CompileStatic
> ---
>
> Key: GROOVY-8788
> URL: https://issues.apache.org/jira/browse/GROOVY-8788
> Project: Groovy
> Issue Type: Bug
> Components: Static compilation, Static Type Checker
>Affects Versions: 2.4.15, 2.5.2
>Reporter: Daniil Ovchinnikov
>Assignee: Eric Milles
>Priority: Major
> Labels: breaking
>
> Given properly registered extension class:
> {code:java|title=MyExtensions.java}
> public class MyExtensions {
> public static void foo(Object self, String s) {
> System.out.println("Object#foo(String)");
> }
> public static void foo(String self, Object o) {
> System.out.println("String#foo(Object)");
> }
> }
> {code}
> Run
> {code:java|title=playground.groovy}
> void usageExt() {
> "".foo("") // prints "Object#foo(String)" which is correct
> }
> @groovy.transform.CompileStatic
> void usageExtStatic() {
> "".foo("") // prints "String#foo(Object)" which is questionable
> }
> usageExt()
> usageExtStatic()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (GROOVY-10726) IntRange#subListBorders gives incorrect values for certain exclusive ranges
[ https://issues.apache.org/jira/browse/GROOVY-10726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul King closed GROOVY-10726. -- Resolution: Not A Problem False alarm. I had forgotten that we store in RangeInfo "to + 1" so that it can be directly used in e.g. subList. > IntRange#subListBorders gives incorrect values for certain exclusive ranges > --- > > Key: GROOVY-10726 > URL: https://issues.apache.org/jira/browse/GROOVY-10726 > Project: Groovy > Issue Type: Bug >Reporter: Paul King >Priority: Major > > We add one instead of subtract one for particular cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (GROOVY-10726) IntRange#subListBorders gives incorrect values for certain exclusive ranges
Paul King created GROOVY-10726: -- Summary: IntRange#subListBorders gives incorrect values for certain exclusive ranges Key: GROOVY-10726 URL: https://issues.apache.org/jira/browse/GROOVY-10726 Project: Groovy Issue Type: Bug Reporter: Paul King We add one instead of subtract one for particular cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
