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, e.g.:

Tuple#concat(...) ... create new instance

Tuple#concatThis(...) ... modify instance
Tuple#concatToThis(...) ... modify instance
Tuple#concatIt(...) ... modify instance

Cheers,
mg


Am 26.11.2018 um 21:19 schrieb Mario Garcia:
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 (<mgbiz@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.asert@gmail.com> escribió:
On Tue, Nov 27, 2018 at 12:34 AM <sunlan@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.