groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Re: groovy git commit: Add missing concat methods of tuples
Date Mon, 26 Nov 2018 23:49:49 GMT
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 
> <mailto: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
>>     <mailto:paul.king.asert@gmail.com>> escribió:
>>
>>         On Tue, Nov 27, 2018 at 12:34 AM <sunlan@apache.org
>>         <mailto: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.
>>
>


Mime
View raw message