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 cannot be modified (it is immutable) (Taken from Julia Lang) - (2) A tuple is a list of N typed objects (Taken from Groovydoc) If (1) it doesn't matter the method name because it's clear to me by its definition that a Tuple is always immutable no matter the method called. If (2) a list in Groovy can be modified, so, maybe method names are important as MG is mentioning Once said that, I prefer the immutable version of tuples as value containers, and I'd vote for changing the Groovydoc definition and enforce immutability to avoid ambiguity. Mario El lun., 26 nov. 2018 a las 20:41, MG (<mg...@arscreat.com>) escribió: > My 2 Cents: I supply two seperate methods in that case, e.g.: > > 1) Columns#sort(...) ... sort the List<Column> collection held by the > Columns class (same name for zero parameters case) > > 2a) Columns#getSorted() ... create new Columns instance with its > List<Column> sorted > 2b) Columns#sorted(...) ... create new Columns instance with its > List<Column> sorted (parameter case) > > Method names should clearly express what the method does (to me the > imperative "sort", compared with the adjective state "(return something > which is) sorted" does that) - nothing worse than you thinking you get a > new instance, and end up modifying the original instance, or thinking you > are working in place, when in fact you are creating new objects all the > time... > > Here: > > Tuple#concat(Tuple) ... modify existing > Tuple#concatenated(Tuple) ... return new instance > > Cheers, > mg > > > Am 26.11.2018 um 19:29 schrieb Mario Garcia: > > 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 <paul.king.as...@gmail.com> > escribió: > >> On Tue, Nov 27, 2018 at 12:34 AM <sun...@apache.org> 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<T1> concat(Tuple0 tuple) { >> > + return new Tuple1<>(v1); >> > + } >> [SNIP] >> >> Returning a new tuple is important? Vs returning this? >> >> Cheers, Paul. >> > >