Hi all, I want to take the opportunity to renew my proposal and PR to add an annotation that allows the override of the Groovy default formatting for certain classes.
https://github.com/apache/groovy/pull/566 To quickly remind you what the problem is, Groovy provides a nice default formatting for some classes i.e. String, Map, and Collection data structures which is good. But it makes impossible to override it by sub-classes that implements their own toString method. The same problem for the `equals` method. This makes difficult to handle some specific use cases, leaving bytecode manipulation as the only alternative. My proposal is to add an annotation named @IgnoreDefaultEqualsAndToString (or maybe @OverrideEqualsAndToString) to bypass the Groovy formatting and allow the invocation of sub-classes `toString` and `equals` methods. I agree that's a sub-optional solution, however no better solutions have been proposed for the current and future releases. Cheers, Paolo On Sun, Jun 25, 2017 at 8:35 PM, Paolo Di Tommaso <paolo.ditomm...@gmail.com > wrote: > 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 >> >> >> >> >> > >> > >
