[
https://issues.apache.org/jira/browse/GROOVY-7522?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keegan Witt updated GROOVY-7522:
--------------------------------
Description:
`@TupleConstructor` and `@Canonical` should not overwrite existing
constructors. So these should work, but don't currently
{code:java}
assert new Cat("Mr. Bigglesworth").name == null
@groovy.transform.TupleConstructor
class Cat {
String name
int age
Cat(String name) {}
}
{code}
{code:java}
assert new Cat("Mr. Bigglesworth").name == null
@groovy.transform.Canonical
class Cat {
String name
int age
Cat(String name) {}
}
{code}
Why aren't the {{includes}}/{{excludes}} annotation elements a sufficient
workaround? Because one might want all the other combinations the
transformation provides, but still have their own implementation for a subset
of the combinations.
was:
`@TupleConstructor` and `@Canonical` should not overwrite existing
constructors. So these should work, but don't currently
{code:java}
assert new Cat("Mr. Bigglesworth").name == null
@groovy.transform.TupleConstructor
class Cat {
String name
int age
Cat(String name) {}
}
{code}
{code:java}
assert new Cat("Mr. Bigglesworth").name == null
@groovy.transform.Canonical
class Cat {
String name
int age
Cat(String name) {}
}
{code}
Why aren't the {{includes}}/{{excludes}} annotation elements a sufficient
workaround? Because one might want all the other combinations the
transformation provides, but still have their own implementation for just one
of the combinations.
> Constructor ASTs shouldn't overwrite existing constructors
> ----------------------------------------------------------
>
> Key: GROOVY-7522
> URL: https://issues.apache.org/jira/browse/GROOVY-7522
> Project: Groovy
> Issue Type: Bug
> Reporter: Keegan Witt
>
> `@TupleConstructor` and `@Canonical` should not overwrite existing
> constructors. So these should work, but don't currently
> {code:java}
> assert new Cat("Mr. Bigglesworth").name == null
> @groovy.transform.TupleConstructor
> class Cat {
> String name
> int age
> Cat(String name) {}
> }
> {code}
> {code:java}
> assert new Cat("Mr. Bigglesworth").name == null
> @groovy.transform.Canonical
> class Cat {
> String name
> int age
> Cat(String name) {}
> }
> {code}
> Why aren't the {{includes}}/{{excludes}} annotation elements a sufficient
> workaround? Because one might want all the other combinations the
> transformation provides, but still have their own implementation for a subset
> of the combinations.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
