You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Paul King <pa...@gmail.com> on 2018/11/26 14:44:34 UTC
Re: groovy git commit: Add missing concat methods of tuples
On Tue, Nov 27, 2018 at 12:34 AM <su...@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.
Re: groovy git commit: Add missing concat methods of tuples
Posted by Daniel Sun <re...@hotmail.com>.
At first tuples should be immutable for better functional programming IMO.
If the operation on tuple does not affact its status, it's OK to return
`this`, i.e. the original tuple(as Paul mentioned)
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: groovy git commit: Add missing concat methods of tuples
Posted by MG <mg...@arscreat.com>.
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
> <ma...@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
>> <ma...@gmail.com>> escribió:
>>
>> On Tue, Nov 27, 2018 at 12:34 AM <sunlan@apache.org
>> <ma...@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.
>>
>
Re: groovy git commit: Add missing concat methods of tuples
Posted by Mario Garcia <ma...@gmail.com>.
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 <pa...@gmail.com>
> escribió:
>
>> On Tue, Nov 27, 2018 at 12:34 AM <su...@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.
>>
>
>
Re: groovy git commit: Add missing concat methods of tuples
Posted by MG <mg...@arscreat.com>.
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
> <ma...@gmail.com>> escribió:
>
> On Tue, Nov 27, 2018 at 12:34 AM <sunlan@apache.org
> <ma...@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.
>
Re: groovy git commit: Add missing concat methods of tuples
Posted by Mario Garcia <ma...@gmail.com>.
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 <pa...@gmail.com> escribió:
> On Tue, Nov 27, 2018 at 12:34 AM <su...@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.
>