[jira] [Updated] (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:all-tabpanel
]
Eric Milles updated GROOVY-9003:
Fix Version/s: (was: 4.x)
> 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
>
> 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
(v8.20.10#820010)
[jira] [Updated] (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:all-tabpanel
]
Paul King updated GROOVY-9003:
--
Fix Version/s: (was: 3.x)
4.x
> 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: 4.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
(v8.3.4#803005)
[jira] [Updated] (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:all-tabpanel
]
paolo di tommaso updated GROOVY-9003:
-
Description:
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.
was:
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 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
> 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] [Updated] (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:all-tabpanel
]
paolo di tommaso updated GROOVY-9003:
-
Description:
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 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 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.
> 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 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)
[jira] [Updated] (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: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)
[jira] [Updated] (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:all-tabpanel
]
paolo di tommaso updated GROOVY-9003:
-
Summary: Allow the override of toString and equals methods for collection
objects (was: Allow the override of `toString` and `equals` methods for
collection objects )
> 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 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.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
