This looks like something that might be useful in certain scenarios. A
"perfect fix" would always be better, but since that might be some time
off (2019 being optimistic - some of the things I want Groovy to improve
in date back to at least 2006)...
My only question would be, if it would perhaps make sense to introduce a
more generically named annotation (@AutomatismOverride, @GroovyOverride,
@Configuration,...), that would allow overriding/fine-tuning many of
Groovy's automatisms through different parameters, to avoid an
annotation-explosion over time ?
mg
On 23.01.2018 09:25, Paolo Di Tommaso wrote:
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 <mailto: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
<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
<mailto: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 <mailto: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
<mailto: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
>>
>>
>
