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, 03 Jun 2016 07:56:24 GMT
Hi,

Thanks for your reply. I see your points and I really hope you can manage
to find a better solution to handle this issue.

In any case I will try to submit a PR at my earliest convenience at least
to have it as remainder in the tracking system.

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