[ https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
paolo di tommaso updated GROOVY-9003: ------------------------------------- Description: Groovy provides a nice string representation for collection objects, however this implementation do not allow custom collection classes to provide own string representation not to implement a custom object identity rule. For example: {code:java} class Mylist extends ArrayList { Mylist(Collection c) { super(c) } @Override boolean equals(Object o) { throw new UnsupportedOperationException () } @Override int hashCode() { throw new UnsupportedOperationException () } @Override String toString() { return 'CUSTOM STRING' } } def l = new Mylist([1,2,3]) assert l.toString() == 'CUSTOM STRING' assert "$l" == '[1, 2, 3]' def q = new Mylist([1,2,3]) assert l.equals(q) assert l == q {code} In the {{Mylist}} class the {{toString}} method is not invoked in the string interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks the java polymorphism contract and create several hassles when implementing custom collection classes. I would propose to fix this behaviour in Groovy 3.0. It would be enough to check in the target class implements the {{toString}} and {{equals}} methods otherwise fallback on the current Groovy behaviour. was: Groovy provides a nice string representation for collection objects, however this implementation do not allow to custom collection class to override their own string representation. For example: {code:java} class Mylist extends ArrayList { Mylist(Collection c) { super(c) } @Override boolean equals(Object o) { throw new UnsupportedOperationException () } @Override int hashCode() { throw new UnsupportedOperationException () } @Override String toString() { return 'CUSTOM STRING' } } def l = new Mylist([1,2,3]) assert l.toString() == 'CUSTOM STRING' assert "$l" == '[1, 2, 3]' def q = new Mylist([1,2,3]) assert l.equals(q) assert l == q {code} In the {{Mylist}} class the {{toString}} method is not invoked in the string interpolation and {{equals}} is not invoked by the {{==}} operator. This breaks the java polymorphism contract and create several hassles when implementing custom collection classes. I would propose to fix this behaviour in Groovy 3.0. It would be enough to check in the target class implements the {{toString}} and {{equals}} methods otherwise fallback on the current Groovy behaviour. > Allow the override of toString and equals methods for collection objects > ------------------------------------------------------------------------- > > Key: GROOVY-9003 > URL: https://issues.apache.org/jira/browse/GROOVY-9003 > Project: Groovy > Issue Type: Improvement > Reporter: paolo di tommaso > Priority: Major > Fix For: 3.x > > > Groovy provides a nice string representation for collection objects, however > this implementation do not allow custom collection classes to provide own > string representation not to implement a custom object identity rule. > For example: > {code:java} > class Mylist extends ArrayList { > Mylist(Collection c) { super(c) } > @Override boolean equals(Object o) { throw new > UnsupportedOperationException () } > @Override int hashCode() { throw new UnsupportedOperationException () } > @Override String toString() { return 'CUSTOM STRING' } > } > def l = new Mylist([1,2,3]) > assert l.toString() == 'CUSTOM STRING' > assert "$l" == '[1, 2, 3]' > def q = new Mylist([1,2,3]) > assert l.equals(q) > assert l == q > {code} > In the {{Mylist}} class the {{toString}} method is not invoked in the string > interpolation and {{equals}} is not invoked by the {{==}} operator. This > breaks the java polymorphism contract and create several hassles when > implementing custom collection classes. > I would propose to fix this behaviour in Groovy 3.0. It would be enough to > check in the target class implements the {{toString}} and {{equals}} methods > otherwise fallback on the current Groovy behaviour. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)