[
https://issues.apache.org/jira/browse/GROOVY-11829?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Eric Milles updated GROOVY-11829:
---------------------------------
Labels: breaking (was: )
> 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
> Assignee: Eric Milles
> Priority: Major
> Labels: breaking
> Fix For: 6.0.0-alpha-1
>
>
> 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)
