Dear all, Groovy still does not provide a mechanism to override the `toString` and `equals` methods for custom Collection and Map objects. This is a serious limitation in some use cases.
I'm proposing with the following pull request to introduce a marker annotation that allows a custom object to use the `toString` and `equals` as expected. https://github.com/apache/groovy/pull/566 Any comment or improvement is welcome. Cheers, Paolo On Thu, Jun 2, 2016 at 1:38 AM, Paul King <pa...@asert.com.au> wrote: > I am +1 on improving how we handle formatting for lists and maps. My > default position would be -1 on an implementation that smells like it > might be "yet another hack" that we have to maintain long term. The > main reason being that we are trying to streamline method selection > for our revised MOP (I know not much is happening in that space right > now) and it would be nicer if once that is done, the "inconsistent" > results you mention could be handled in an easy to understand way. > Having said that, if I get time to look into it further and can't > think of a better way to approach it long term, then I could easily be > moved to at least a -0. > > Cheers, Paul. > > On Tue, May 31, 2016 at 7:36 PM, Paolo Di Tommaso > <paolo.ditomm...@gmail.com> wrote: > > Hello guys, > > > > No feedback on this? Would you take in consideration a PR for this > proposal? > > > > > > Thanks, > > Paolo > > > > > > On Sat, May 28, 2016 at 6:26 PM, Paolo Di Tommaso > > <paolo.ditomm...@gmail.com> wrote: > >> > >> Hi all, > >> > >> Groovy implements a built-in formatting strategy for collection and map > >> objects that is surely nicer and more useful than the one provided by > the > >> default Java implementation for these classes. > >> > >> However there are use cases in which custom collection or map classes > need > >> to implement their own formatting rule. > >> > >> Currently in Groovy this is quite painful and may lead to inconsistent > >> results. Take in consideration the following example: > >> > >> class MyList extends ArrayList { > >> String toString() { > >> this.join('-') > >> } > >> } > >> > >> def x = new MyList() > >> x << 1 << 2 << 3 > >> > >> println x.toString() > >> println x > >> println "$x" > >> > >> Which prints: > >> > >> 1-2-3 > >> [1, 2, 3] > >> [1, 2, 3] > >> > >> Both the second and third `println` use the Groovy built-in formatting > >> method and there's no easy way to override this behaviour. Also there's > not > >> a clear reason why the first and the second print return a different > output. > >> > >> The only options I've found is to define `MyList` with a @Delegate > without > >> implementing the `List` interface. But this leads to other weird side > >> effects. The remaining possibility is to use some bytecode manipulation > to > >> bypass the default Groovy formatting, but it looks to me a really > >> overkilling solution for such problem. > >> > >> For this reason a would like to propose to introduce a mechanism that > >> would allow custom collection and map classes to bypass the default > >> formatting method. This should not be too difficult. The current Groovy > >> built-in formatting is implemented by formatList and formatMap methods. > >> > >> It would be enough to add a marker interface (or an annotation) that > when > >> applied to a class it would be used to by-pass the logic in the > formatList > >> and formatMap methods and simply return the string provided by the > object > >> `toString` method. > >> > >> > >> I could easily contribute this patch however I would know the opinion of > >> the Groovy core committers. In particular: > >> > >> 1) What name should have this marker interface? groovy.lagn.Something? > >> 2) Are formatList and formatMap methods the right place to add this > logic? > >> 3) A similar problem exists also when using the `equals` (and hashCode?) > >> method for collections and maps. Should this mechanism be extended also > to > >> this case? > >> > >> > >> > >> Best, > >> Paolo > >> > >> > > >
