At first tuples should be immutable for better functional programming IMO.
If the operation on tuple does not affact its status, it's OK to return
`this`, i.e. the original tuple(as Paul mentioned)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
You are right, but I still think it would be a good idea to consider
introducing a general method naming convention, whatever is decided for
Tuple (going all immutable or not).
Since frameworks/languages are moving towards more immutability, the
convention could of course favor that case,
Apparently the actual Tuple implementation in main branch is creating new
tuples when doing tuple.concat(tuple) (not all but most of), so I guess is
just a matter of making sure what a Tuple is in Groovy. Two options:
- (1) A tuple is a fixed-length container that can hold any values, but
My 2 Cents: I supply two seperate methods in that case, e.g.:
1) Columns#sort(...) ... sort the List collection held by the
Columns class (same name for zero parameters case)
2a) Columns#getSorted() ... create new Columns instance with its
List sorted
2b) Columns#sorted(...) ... create new
I'd do it if the intention is to enforce immutability of tuples, like
"...any operation applied to a tuple should result in a new tuple"
Regards
Mario
El lun., 26 nov. 2018 15:44, Paul King escribió:
> On Tue, Nov 27, 2018 at 12:34 AM wrote:
> >
> > Repository: groovy
> > Updated Branches:
>
On Tue, Nov 27, 2018 at 12:34 AM wrote:
>
> Repository: groovy
> Updated Branches:
> refs/heads/master aa372c484 -> b6933c7ef
>
>
> Add missing concat methods of tuples
[SNIP]
> /**
> * Concatenate a tuple to this tuple.
> */
> +public final Tuple1 concat(Tuple0 tuple) {
>
