[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16776144#comment-16776144
]
paolo di tommaso edited comment on GROOVY-9003 at 2/24/19 7:45 AM:
---
In principle seems to work, it could be something along these lines:
{code}
Object.metaClass.toString = { ->
if( delegate instanceof List )
return delegate.join('-')
else
return 'foo'
}
class Foo {
}
class Bar {
String toString() { return 'bar' }
}
def f = new Foo()
def b = new Bar()
assert f.toString() =='foo'
assert b.toString() == 'bar'
{code}
However, I've also realised that the following won't work due to GROOVY-2599
{code:java}
assert "$f" =='foo'
{code}
A good opportunity to solve this as well and make string representation
coherent.
was (Author: pablo72):
In principle seems to work, the is something along these lines:
{code}
Object.metaClass.toString = { ->
if( delegate instanceof List )
delegate.join('-')
else
'foo'
}
class Foo {
}
class Bar {
String toString() { return 'bar' }
}
def f = new Foo()
def b = new Bar()
assert f.toString() =='foo'
assert b.toString() == 'bar'
{code}
However, I've also realised that the following won't work due to GROOVY-2599
{code:java}
assert "$f" =='foo'
{code}
A good opportunity to solve this as well and make string representation
coherent.
> 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)
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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)
[jira] [Comment Edited] (GROOVY-9003) Allow the override of toString and equals methods for collection objects
[
https://issues.apache.org/jira/browse/GROOVY-9003?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=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 (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}
was (Author: pablo72):
I should have clarified better, the proposal is to skip the groovy
representation when 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)
