Add a marker interface to bypass Collections and Maps formatting

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Add a marker interface to bypass Collections and Maps formatting

Paolo Di Tommaso
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
 

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add a marker interface to bypass Collections and Maps formatting

Paolo Di Tommaso
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 <[hidden email]> 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
 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add a marker interface to bypass Collections and Maps formatting

paulk_asert
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
<[hidden email]> 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
> <[hidden email]> 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
>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add a marker interface to bypass Collections and Maps formatting

Paolo Di Tommaso
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 <[hidden email]> 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
<[hidden email]> 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
> <[hidden email]> 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
>>
>>
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Add a marker interface to bypass Collections and Maps formatting

Paolo Di Tommaso
In reply to this post by paulk_asert
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. 



Any comment or improvement is welcome. 


Cheers,
Paolo


On Thu, Jun 2, 2016 at 1:38 AM, Paul King <[hidden email]> 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
<[hidden email]> 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
> <[hidden email]> 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
>>
>>
>

Loading...