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