groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: Add a marker interface to bypass Collections and Maps formatting
Date Thu, 25 Jan 2018 22:53:16 GMT
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 <mailto: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
>     <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
>     <mailto: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 <mailto: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
>         <mailto: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