groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Garcia <mario.g...@gmail.com>
Subject Re: groovy git commit: Add missing concat methods of tuples
Date Mon, 26 Nov 2018 20:19:08 GMT
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.
>>
>
>

Mime
View raw message