groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "paolo di tommaso (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
Date Fri, 22 Feb 2019 07:38:00 GMT

    [ 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 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}


was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy representation when a class
*declares* the `toString` method (it 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)

Mime
View raw message