[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16774862#comment-16774862
]
paolo di tommaso edited comment on GROOVY-9003 at 2/22/19 7:37 AM:
-------------------------------------------------------------------
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (i.e.
getDeclaredMethod vs getMethod). In this case, from the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy
representation when a class *declares* the `toString` method (i.e.
getDeclaredMethod vs getMethod). In this case between the mentioned classes
remain the following:
{code}
Vector, ArrayBlockingQueue, LinkedBlockingDeque, LinkedBlockingQueue,
PriorityBlockingQueue
{code}
However it should be noted that the string representation they implement is the
same as the groovy one.
{code}
def v = new Vector()
v << 1
v << 'hello'
v << 'world'
def a = new java.util.concurrent.ArrayBlockingQueue(1)
a << 1
a << 'hello'
a << 'world'
assert v.toString() == "$v"
assert a.toString() == "$a"
{code}
> 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
> the current behaviour 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 if 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)
