[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16774607#comment-16774607
]
Paul King commented on GROOVY-9003:
-----------------------------------
I think we should do something but it may not be as simple as we'd like and
we'll need to promote it widely. For example, the following classes have their
own toString:
{noformat}
Vector, ConcurrentLinkedQueue, ArrayBlockingQueue, LinkedBlockingDeque,
LinkedBlockingQueue, PriorityBlockingQueue, LinkedTransferQueue,
SynchronousQueue
{noformat}
while these ones would normally rely on the toString from AbstractCollection
and would get the pretty Groovy representation in your proposed solution:
{noformat}
ArrayList, LinkedList, DelayQueue, PriorityQueue, ConcurrentSkipListSet,
CopyOnWriteArraySet, HashSet, TreeSet, ArrayDeque, EnumSet
{noformat}
This might not be a bad thing but will be a little unexpected for some.
> 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)
