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
<mailto:paul.king.as...@gmail.com>> escribió:
On Tue, Nov 27, 2018 at 12:34 AM <sun...@apache.org
<mailto: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.
