[
https://issues.apache.org/jira/browse/GROOVY-11829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luke Bemish updated GROOVY-11829:
---------------------------------
Description:
Groovy treats `set` methods as arbitrary property setters; for example, the
following
{code:groovy}
class Foo {
void set(String key, String value) {
println "Setting $key to $value (String)"
}
static void main(String[] args) {
def foo = new Foo()
foo.exampleKey = "exampleValue"
}
} {code}
Will print the expected method. However, this behaviour is strange if multiple
`set` methods exist. For instance, if we have
{code:groovy}
void set(String key, String value) {
println "Setting $key to $value (String)"
}
void set(String key, Number value) {
println "Setting $key to $value (Number)"
} {code}
Then a runtime call
{code:groovy}
foo.exampleKey = "exampleValue"{code}
Will throw, as it will attempt (and fail) to convert the value to a Number
instead of picking the best match method. Worse, the following will type-check
under CompileStatic:
{code:groovy}
foo["exampleKey"] = "exampleValue" {code}
But throw with a GroovyCastException at runtime. It would be useful –
especially when writing code to be interfaced with from either java or groovy –
if this instead picked the best-matching overload of `set` and used that.
was:
Groovy treats `set` methods as arbitrary property setters; for example, the
following
{code:groovy}
class Foo {
void set(String key, String value) {
println "Setting $key to $value (String)"
}
static void main(String[] args) {
def foo = new Foo()
foo.exampleKey = "exampleValue"
}
} {code}
Will print the expected method. However, this behaviour is strange if multiple
`set` methods exist. For instance, if we have
{code:groovy}
void set(String key, String value) {
println "Setting $key to $value (String)"
}
void set(String key, Number value) {
println "Setting $key to $value (Number)"
} {code}
Then a runtime call
{code:groovy}
foo.exampleKey = "exampleValue"{code}
Will throw, as it will attempt (and fail) to convert the value to a Number
instead of picking the best match method. Worse, the following will type-check
under CompileStatic:
{code:groovy}
foo["exampleKey"] = "exampleValue" {code}
But throw with a ClassCastException at runtime. It would be useful – especially
when writing code to be interfaced with from either java or groovy – if this
instead picked the best-matching overload of `set` and used that.
> Properties located from a set(key, value) always use the same method even
> when the value type is better matched by another
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-11829
> URL: https://issues.apache.org/jira/browse/GROOVY-11829
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 4.0.29, 5.0.3
> Reporter: Luke Bemish
> Priority: Major
>
> Groovy treats `set` methods as arbitrary property setters; for example, the
> following
> {code:groovy}
> class Foo {
> void set(String key, String value) {
> println "Setting $key to $value (String)"
> }
> static void main(String[] args) {
> def foo = new Foo()
> foo.exampleKey = "exampleValue"
> }
> } {code}
> Will print the expected method. However, this behaviour is strange if
> multiple `set` methods exist. For instance, if we have
> {code:groovy}
> void set(String key, String value) {
> println "Setting $key to $value (String)"
> }
> void set(String key, Number value) {
> println "Setting $key to $value (Number)"
> } {code}
> Then a runtime call
> {code:groovy}
> foo.exampleKey = "exampleValue"{code}
> Will throw, as it will attempt (and fail) to convert the value to a Number
> instead of picking the best match method. Worse, the following will
> type-check under CompileStatic:
> {code:groovy}
> foo["exampleKey"] = "exampleValue" {code}
> But throw with a GroovyCastException at runtime. It would be useful –
> especially when writing code to be interfaced with from either java or groovy
> – if this instead picked the best-matching overload of `set` and used that.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
