groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paolo Di Tommaso <paolo.ditomm...@gmail.com>
Subject Re: Add a marker interface to bypass Collections and Maps formatting
Date Fri, 26 Jan 2018 14:21:09 GMT
I agree. The name @GroovyOverride sounds a good option.



Cheers,
Paolo


On Thu, Jan 25, 2018 at 11:53 PM, MG <mgbiz@arscreat.com> wrote:

> 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.ditommaso@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 <paulk@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.ditommaso@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.ditommaso@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
>>> >>
>>> >>
>>> >
>>>
>>
>>
>
>

Mime
View raw message