.with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

Hi everyone,

We are hoping to release 2.5 not too far down the track. We are
working on a revamped release process that is going to dramatically
improve our ability to release early/release often but also comply
with some additional Apache requirements that we follow these days.
But more on that another time.

One outstanding feature request targeted for potential inclusion in
2.5 is an alternative to .with{} that automatically returns the
original object after executing the closure - recall that .with{}
returns the last evaluated expression. The proposal is here:

https://github.com/apache/groovy/pull/174/files

We can't use the old name since that would break backward
compatibility and is of utility in its current form in any case, so we
are looking for a new name for the proposed method. If you look at the
PR you will see it has been called 'tap' and 'doto' and numerous other
names have been suggested. We regard naming as very important and
normally we'd have very strong views about suitable names based on
functionality and similar method names within the Groovy codebase. But
in this instance, an obvious name hasn't popped out at us, so we are
requesting feedback from the community about what names make most
sense to you.

Firstly, here is what the method does. I'll use 'tap' in these
examples since that is what the PR currently uses but we can easily
change that based on feedback.

myObject.tap {
    // some code
}

is equivalent to:

myObject.with {
    // some code
    return this
}

Returning the 'self' object lends itself to various kinds of chaining, e.g.

assert [:].tap {
    a = 1
}.tap {
    b = 2
} == [a:1, b:2]

Or this one (adapted from a blog post[1] - and assuming you have a
config.properties file containing answer=42 as one of the properties):

assert new Properties().tap {
    new FileInputStream('config.properties').withCloseable {
        load(it)
    }
}.answer == '42'

Here are some of the names that have been suggested with some commentary:

doto    Used by Clojure. Not camel case as per normal convention
(though we have upto and downto which also break that convention) and
it isn't immediately obvious which is which between with and doto just
from the names

tap    Comes from Ruby and a previous Groovy extension outside core
exists; meant to conjure up the idea of tapping into an object

autoWith    Same as with but automatically returns self

doWith   Again, hard to distinguish between doWith and with from the
names themselves

tee    An alternative name for tap

auto    A shortened version of 'autoWith'

apply    same as Kotlin which has copied Groovy's with but suffers
from the downside that apply is already heavily overleaded in other
contexts, e.g. functional programming

withThis    Distinction with normal with a bit subtle perhaps

asThis    Ditto

within    Ditto

I'll also point out the 'identity' is currently an alias for 'with',
in case that provides any additional inspiration.

Perhaps you dis/like one of the above or have some other suggestions.
Let us know.


Cheers, Paul.


[1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/

Re: .with() variant that returns the original object

[OC <oc...@ocs.cz>]

P.S. Perhaps "resultWith" or "resultTapping" would be even better than "valueXXX".

On 8. 11. 2016, at 16:15, OC <oc...@ocs.cz> wrote:

> Hi there,
> 
> as always I can be wrong, but I do not think it is possible to find a good name which (a) expresses the behaviour well (b) along with its very close similarity to 'with', which is a problem of 'tap's etc can be found.
> 
> Therefore myself, I would advocate for
> 
> (a) **renaming current 'with'** (keeping, of course, the original name as an equivalent for backward compatibility; just by convention discourage its use in new code)
> (b) and adding an appropriate variant of the name for the new functionality.
> 
> Myself, I would probably like
> 
> - 'doWith' for the new one -- considering returning 'this' a reasonable default, which it is
> - 'valueWith' as a modern equivalent of 'with' for the old functionality
> 
> or perhaps
> 
> - 'tap' for the new one (for all the reasons others expressed in favour of the name)
> - 'valueTapping' as a modern equivalent of 'with' for the old functionality
> 
> or something like that.
> 
> All the best,
> OC
> 
> 
> On 8. 11. 2016, at 15:34, Paul King <pa...@asert.com.au> wrote:
> 
>> Hi everyone,
>> 
>> We are hoping to release 2.5 not too far down the track. We are
>> working on a revamped release process that is going to dramatically
>> improve our ability to release early/release often but also comply
>> with some additional Apache requirements that we follow these days.
>> But more on that another time.
>> 
>> One outstanding feature request targeted for potential inclusion in
>> 2.5 is an alternative to .with{} that automatically returns the
>> original object after executing the closure - recall that .with{}
>> returns the last evaluated expression. The proposal is here:
>> 
>> https://github.com/apache/groovy/pull/174/files
>> 
>> We can't use the old name since that would break backward
>> compatibility and is of utility in its current form in any case, so we
>> are looking for a new name for the proposed method. If you look at the
>> PR you will see it has been called 'tap' and 'doto' and numerous other
>> names have been suggested. We regard naming as very important and
>> normally we'd have very strong views about suitable names based on
>> functionality and similar method names within the Groovy codebase. But
>> in this instance, an obvious name hasn't popped out at us, so we are
>> requesting feedback from the community about what names make most
>> sense to you.
>> 
>> Firstly, here is what the method does. I'll use 'tap' in these
>> examples since that is what the PR currently uses but we can easily
>> change that based on feedback.
>> 
>> myObject.tap {
>>   // some code
>> }
>> 
>> is equivalent to:
>> 
>> myObject.with {
>>   // some code
>>   return this
>> }
>> 
>> Returning the 'self' object lends itself to various kinds of chaining, e.g.
>> 
>> assert [:].tap {
>>   a = 1
>> }.tap {
>>   b = 2
>> } == [a:1, b:2]
>> 
>> Or this one (adapted from a blog post[1] - and assuming you have a
>> config.properties file containing answer=42 as one of the properties):
>> 
>> assert new Properties().tap {
>>   new FileInputStream('config.properties').withCloseable {
>>       load(it)
>>   }
>> }.answer == '42'
>> 
>> Here are some of the names that have been suggested with some commentary:
>> 
>> doto    Used by Clojure. Not camel case as per normal convention
>> (though we have upto and downto which also break that convention) and
>> it isn't immediately obvious which is which between with and doto just
>> from the names
>> 
>> tap    Comes from Ruby and a previous Groovy extension outside core
>> exists; meant to conjure up the idea of tapping into an object
>> 
>> autoWith    Same as with but automatically returns self
>> 
>> doWith   Again, hard to distinguish between doWith and with from the
>> names themselves
>> 
>> tee    An alternative name for tap
>> 
>> auto    A shortened version of 'autoWith'
>> 
>> apply    same as Kotlin which has copied Groovy's with but suffers
>> from the downside that apply is already heavily overleaded in other
>> contexts, e.g. functional programming
>> 
>> withThis    Distinction with normal with a bit subtle perhaps
>> 
>> asThis    Ditto
>> 
>> within    Ditto
>> 
>> I'll also point out the 'identity' is currently an alias for 'with',
>> in case that provides any additional inspiration.
>> 
>> Perhaps you dis/like one of the above or have some other suggestions.
>> Let us know.
>> 
>> 
>> Cheers, Paul.
>> 
>> 
>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/
> 

Re: .with() variant that returns the original object

[OC <oc...@ocs.cz>]

Hi there,

as always I can be wrong, but I do not think it is possible to find a good name which (a) expresses the behaviour well (b) along with its very close similarity to 'with', which is a problem of 'tap's etc can be found.

Therefore myself, I would advocate for

(a) **renaming current 'with'** (keeping, of course, the original name as an equivalent for backward compatibility; just by convention discourage its use in new code)
(b) and adding an appropriate variant of the name for the new functionality.

Myself, I would probably like

- 'doWith' for the new one -- considering returning 'this' a reasonable default, which it is
- 'valueWith' as a modern equivalent of 'with' for the old functionality

or perhaps

- 'tap' for the new one (for all the reasons others expressed in favour of the name)
- 'valueTapping' as a modern equivalent of 'with' for the old functionality

or something like that.

All the best,
OC


On 8. 11. 2016, at 15:34, Paul King <pa...@asert.com.au> wrote:

> Hi everyone,
> 
> We are hoping to release 2.5 not too far down the track. We are
> working on a revamped release process that is going to dramatically
> improve our ability to release early/release often but also comply
> with some additional Apache requirements that we follow these days.
> But more on that another time.
> 
> One outstanding feature request targeted for potential inclusion in
> 2.5 is an alternative to .with{} that automatically returns the
> original object after executing the closure - recall that .with{}
> returns the last evaluated expression. The proposal is here:
> 
> https://github.com/apache/groovy/pull/174/files
> 
> We can't use the old name since that would break backward
> compatibility and is of utility in its current form in any case, so we
> are looking for a new name for the proposed method. If you look at the
> PR you will see it has been called 'tap' and 'doto' and numerous other
> names have been suggested. We regard naming as very important and
> normally we'd have very strong views about suitable names based on
> functionality and similar method names within the Groovy codebase. But
> in this instance, an obvious name hasn't popped out at us, so we are
> requesting feedback from the community about what names make most
> sense to you.
> 
> Firstly, here is what the method does. I'll use 'tap' in these
> examples since that is what the PR currently uses but we can easily
> change that based on feedback.
> 
> myObject.tap {
>    // some code
> }
> 
> is equivalent to:
> 
> myObject.with {
>    // some code
>    return this
> }
> 
> Returning the 'self' object lends itself to various kinds of chaining, e.g.
> 
> assert [:].tap {
>    a = 1
> }.tap {
>    b = 2
> } == [a:1, b:2]
> 
> Or this one (adapted from a blog post[1] - and assuming you have a
> config.properties file containing answer=42 as one of the properties):
> 
> assert new Properties().tap {
>    new FileInputStream('config.properties').withCloseable {
>        load(it)
>    }
> }.answer == '42'
> 
> Here are some of the names that have been suggested with some commentary:
> 
> doto    Used by Clojure. Not camel case as per normal convention
> (though we have upto and downto which also break that convention) and
> it isn't immediately obvious which is which between with and doto just
> from the names
> 
> tap    Comes from Ruby and a previous Groovy extension outside core
> exists; meant to conjure up the idea of tapping into an object
> 
> autoWith    Same as with but automatically returns self
> 
> doWith   Again, hard to distinguish between doWith and with from the
> names themselves
> 
> tee    An alternative name for tap
> 
> auto    A shortened version of 'autoWith'
> 
> apply    same as Kotlin which has copied Groovy's with but suffers
> from the downside that apply is already heavily overleaded in other
> contexts, e.g. functional programming
> 
> withThis    Distinction with normal with a bit subtle perhaps
> 
> asThis    Ditto
> 
> within    Ditto
> 
> I'll also point out the 'identity' is currently an alias for 'with',
> in case that provides any additional inspiration.
> 
> Perhaps you dis/like one of the above or have some other suggestions.
> Let us know.
> 
> 
> Cheers, Paul.
> 
> 
> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/

RE: .with() variant that returns the original object

["Winnebeck, Jason" <Ja...@windstream.com>]

Yes, and the code in my e-mail is wrong, it should be .with {it} not .with{this}, which would end up returning the reference to the closure.

Jason

From: Cédric Champeau [mailto:cedric.champeau@gmail.com]
Sent: Wednesday, November 09, 2016 9:03 AM
To: users@groovy.apache.org
Cc: paulk@asert.com.au
Subject: Re: .with() variant that returns the original object

I agree with what Jason said. I'm still up for `tap`. We could use `with(true) { ... }`, but I also dislike "with(returnThis: true) {... }" because it's not type safe.



2016-11-09 14:56 GMT+01:00 Winnebeck, Jason <Ja...@windstream.com>>:
My concern about "withThis" is that it implies that "this" is the parameter of the closure and not the return. We have for example withReader, withWriter, withOutputStream, etc. Those all imply that the parameter is the reader, the writer, the output stream. So in my mind, withThis tells me nothing at all about the fact that the original object is returned. withThis would not be consistent with the rest of Groovy.

.with(returnThis:true) not only has runtime overhead, but keep in mind we are comparing this to the current state today, which is .with { return this }, or .with { this } depending on your style. So anything we pick needs to be shorter or more obvious than that, if not, then we should do nothing and just tell people to end the closure with "return this", or even just "this". That's why I would vote against .withReturnThis or .with(returnThis:true), or the equally cryptic .with(true).

Jason Winnebeck

-----Original Message-----
From: Philip Mitchell [mailto:pjmitchell@blueyonder.co.uk<ma...@blueyonder.co.uk>]
Sent: Tuesday, November 08, 2016 7:53 PM
To: users@groovy.apache.org<ma...@groovy.apache.org>; paulk@asert.com.au<ma...@asert.com.au>
Subject: Re: .with() variant that returns the original object

+1 for withThis()
-1 tap()

I agree with the point below. Given this is virtually identical to the existing with() method, the new methods name should reflect that. Consistency within Groovy and it’s existing libraries counts for more than consistency with what the method is called in another language.

I see comments below that tap() makes more sense once explained, but I would argue that the fact it needs explained is enough of a reason to reject it. I lean toward method names that clearly express what they do. tap() seem cryptic. The name withThis() has the virtue of being reasonably descriptive as well as being consistent with the existing with() method name.

Just my 2-cents worth.

Phil Mitchell


> On 8 Nov 2016, at 23:49, Paul King <pa...@asert.com.au>> wrote:
>
> Well we certainly could have as per Jochen's suggestion a DGM method
> roughly like:
>
> public static with(def self, boolean returnThis, Closure closure) {
> ... }
>
> and for backwards compatibility returnThis would default to false,
> i.e. with(closure) and identity(closure) are an alias for with(false,
> closure) and tap would be an alias for with(true, closure)
>
> I think it is worth having the alias, if nothing else for better type
> inferencing we'll get from the signatures but also letting people
> choose between tap and with(true).
>
> Cheers, Paul.
>
>
> On Wed, Nov 9, 2016 at 9:02 AM, Henrik Martin <he...@netgate.net>> wrote:
>> +1 for withThis or withValue and +10 for Jochen's overloading
>> +proposal if
>> it's feasible.
>> -1000 for tap. Completely nonsensical to me and makes me think of
>> network tun/tap interfaces in Linux or something like that. Isn't the
>> functionality a little bit like the Builder pattern more than a pipeline of commands?
>> Maybe I'm misunderstanding the whole thing. Either way, to introduce
>> a completely new name for something that is already named and simply
>> augmented in terms of functionality seems very confusing and counter intuitive to me.
>> Imagine a Groovy newbie that reads a tutorial or reference manual and
>> first learns about with(). Then a little further on, tap() is
>> introduced. I would immediately think "why on earth did they name
>> these things completely differently, when one is essentially a
>> variant of the other???". Again, forgive me if I'm completely misunderstanding the context here.
>>
>> -Henrik
>>
>> On 11/8/16 10:16 AM, Gerald Wiltse wrote:
>>
>> Some really neat and creative suggestions here suddenly. Still happy
>> with any name, but I do like "withThis"  and "having",  However, tap
>> seems to be gaining momentum and with good reasons, despite the
>> common complaint of "What the heck does tap mean".  I agree it makes more sense after explained.
>>
>> Gerald R. Wiltse
>> jerrywiltse@gmail.com<ma...@gmail.com>
>>
>>
>> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <ma...@mac.com>> wrote:
>>>
>>> +1 for tap.  Concise and makes sense once explained (even intuitive
>>> +to
>>> some).
>>>
>>> Have you ever tried to find usages of with in groovy with code
>>> examples with google without eventually loosing your temper ?
>>>
>>> For one thing, I think tap will be easier to google for.
>>>
>>> Marc Paquette
>>>
>>> Le 8 nov. 2016 à 12:32, Suderman Keith <su...@anc.org>> a écrit :
>>>
>>>
>>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <bl...@gmx.org>> wrote:
>>>
>>> what about an overloaded with:
>>>
>>>
>>> +1
>>>
>>> Or even something like:
>>>
>>> myObject.with { ... } // current behaviour
>>> myObject.with(return:this) { ... } // returns this when finished.
>>> myObejct.with(return:new Object()) { ... } // returns a new Object
>>> when finished.
>>>
>>> This particular syntax would take a bit of extra parser arm waving
>>> since the `return` keyword is being used differently in this context.
>>>
>>> Keith
>>>
>>>
>>> myObject.with(true) {
>>>  // some code
>>> }
>>>
>>>
>>> or:
>>>
>>> myObject.with(returnThis:true) {
>>>  // some code
>>> }
>>>
>>>
>>> or... well I am sure there are many variants... just want to know if
>>> something like this doesn't cut it.
>>>
>>> bye Jochen
>>>
>>>
>>>
>>
>>

This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

On Thu, Nov 10, 2016 at 6:47 AM, James Kleeh <ja...@gmail.com> wrote:
> What about something like object.build { } ?

If you are solely using 'with' to build an object and 'with' by itself
isn't good enough Groovy also has the @Builder annotation. Probably
best we don't confuse normal 'with' with the @Builder transform which
already by default has a 'build' method:

http://groovy-lang.org/metaprogramming.html#xform-Builder

Re: .with() variant that returns the original object

[James Kleeh <ja...@gmail.com>]

What about something like object.build { } ?

> On Nov 9, 2016, at 3:45 PM, Jordan Martinez <jo...@gmail.com> wrote:
> 
> What about `object.itselfWith(Closure)`? Then its understood as returning the object itself but with the changes that follow.
> 
> Blessings,
> Jordan
> 
> On Wed, Nov 9, 2016 at 12:32 PM, Paul King <paulk@asert.com.au <ma...@asert.com.au>> wrote:
> On Thu, Nov 10, 2016 at 12:02 AM, Cédric Champeau
> <cedric.champeau@gmail.com <ma...@gmail.com>> wrote:
> > I agree with what Jason said. I'm still up for `tap`. We could use
> > `with(true) { ... }`, but I also dislike "with(returnThis: true) {... }"
> > because it's not type safe.
> 
> If we progress GROOVY-7956, we'd have type safety but I agree with you
> anyway. And it should be returnImplicitThis or returnSelf or something
> anyway.
> 
> Cheers, Paul.
> 

RE: .with() variant that returns the original object

["Winnebeck, Jason" <Ja...@windstream.com>]

I agree, assuming that tap is not overloaded in any other popular use or language, it is not likely we would want to define tap in another way. Then we can appease both viewpoints. The other very important reason for with(boolean, Closure) and tap is that unfortunately .with(boolean, Closure) will always trigger warning about not returning from IDE, while tap can declare Closure<Void> I think which hopefully can trigger IDE to say no return is needed?

Jason

From: Søren Berg Glasius (GR8Conf EU) [mailto:sbglasius@gr8conf.org]
Sent: Tuesday, November 15, 2016 3:51 AM
To: users@groovy.apache.org
Subject: Re: .with() variant that returns the original object

+1

I like that you provide both .with(true, Closure) and .tap(Closure)

Best regards,
Søren Berg Glasius
GR8Conf Europe organizing team

GR8Conf ApS
Mobile: +45 40 44 91 88, Web: www.gr8conf.eu<http://www.gr8conf.eu/>, Skype: sbglasius
Company Address: Buchwaldsgade 50, 5000 Odense C, Denmark
Personal Address: Hedevej 1, Gl. Rye, 8680 Ry, Denmark
--- GR8Conf - Dedicated to the Groovy Ecosystem

From: Guillaume Laforge <gl...@gmail.com>
Reply: users@groovy.apache.org<ma...@groovy.apache.org> <us...@groovy.apache.org>
Date: 15. november 2016 at 09.24.36
To: users@groovy.apache.org<ma...@groovy.apache.org> <us...@groovy.apache.org>, Paul King <pa...@asert.com.au>
Subject:  Re: .with() variant that returns the original object


Sounds good to me!

On Tue, Nov 15, 2016 at 9:17 AM, Paul King <pa...@asert.com.au>> wrote:
Ok, disussion seems to have finished on this topic. I was planning to
merge Christoph's PR with minor tweaks as needed. I was going to use
'tap' as the name.

At this stage, unless I hear violent objections, I was also planning
to provide the additional variant that was discussed:

with(boolean returning, Closure closure)

so folks could use with(true) if they wanted. It's a little clunky but
is the kind of thing we do in other places within Groovy, provides an
alternative for anyone that finds 'tap' totally foreign and might also
help steer users between the two related methods.

Cheers, Paul.


On Thu, Nov 10, 2016 at 3:04 PM, Paul King <pa...@asert.com.au>> wrote:
> On Thu, Nov 10, 2016 at 6:45 AM, Jordan Martinez
> <jo...@gmail.com>> wrote:
>> What about `object.itselfWith(Closure)`? Then its understood as returning
>> the object itself but with the changes that follow.
>
> Both variants use 'itself' but only one returns 'itself', so I would
> regard that prefix as not distinguishing enough. You'd need something
> like 'withThen' or 'withReturning' to help distinguish between the
> two. The problem with 'withReturning' is that it is longer
> (character-wise) than 'with(true)' or just adding 'return it' or 'it'
> to the end of the closure - not that numbers of characters alone
> should be the most important metric.
>
> Cheers, Paul.



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge<http://twitter.com/glaforge> / Google+<https://plus.google.com/u/0/114130972232398734985/posts>

This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

Re: .with() variant that returns the original object

["Søren Berg Glasius (GR8Conf EU)" <sb...@gr8conf.org>]

+1

I like that you provide both .with(true, Closure) and .tap(Closure)

Best regards,
Søren Berg Glasius
GR8Conf Europe organizing team

GR8Conf ApS
Mobile: +45 40 44 91 88, Web: www.gr8conf.eu, Skype: sbglasius
Company Address: Buchwaldsgade 50, 5000 Odense C, Denmark
Personal Address: Hedevej 1, Gl. Rye, 8680 Ry, Denmark
--- GR8Conf - Dedicated to the Groovy Ecosystem

From: Guillaume Laforge <gl...@gmail.com> <gl...@gmail.com>
Reply: users@groovy.apache.org <us...@groovy.apache.org>
<us...@groovy.apache.org>
Date: 15. november 2016 at 09.24.36
To: users@groovy.apache.org <us...@groovy.apache.org>
<us...@groovy.apache.org>, Paul King <pa...@asert.com.au>
<pa...@asert.com.au>
Subject:  Re: .with() variant that returns the original object

Sounds good to me!

On Tue, Nov 15, 2016 at 9:17 AM, Paul King <pa...@asert.com.au> wrote:

> Ok, disussion seems to have finished on this topic. I was planning to
> merge Christoph's PR with minor tweaks as needed. I was going to use
> 'tap' as the name.
>
> At this stage, unless I hear violent objections, I was also planning
> to provide the additional variant that was discussed:
>
> with(boolean returning, Closure closure)
>
> so folks could use with(true) if they wanted. It's a little clunky but
> is the kind of thing we do in other places within Groovy, provides an
> alternative for anyone that finds 'tap' totally foreign and might also
> help steer users between the two related methods.
>
> Cheers, Paul.
>
>
> On Thu, Nov 10, 2016 at 3:04 PM, Paul King <pa...@asert.com.au> wrote:
> > On Thu, Nov 10, 2016 at 6:45 AM, Jordan Martinez
> > <jo...@gmail.com> wrote:
> >> What about `object.itselfWith(Closure)`? Then its understood as
> returning
> >> the object itself but with the changes that follow.
> >
> > Both variants use 'itself' but only one returns 'itself', so I would
> > regard that prefix as not distinguishing enough. You'd need something
> > like 'withThen' or 'withReturning' to help distinguish between the
> > two. The problem with 'withReturning' is that it is longer
> > (character-wise) than 'with(true)' or just adding 'return it' or 'it'
> > to the end of the closure - not that numbers of characters alone
> > should be the most important metric.
> >
> > Cheers, Paul.
>



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>

Re: .with() variant that returns the original object

[Guillaume Laforge <gl...@gmail.com>]

Sounds good to me!

On Tue, Nov 15, 2016 at 9:17 AM, Paul King <pa...@asert.com.au> wrote:

> Ok, disussion seems to have finished on this topic. I was planning to
> merge Christoph's PR with minor tweaks as needed. I was going to use
> 'tap' as the name.
>
> At this stage, unless I hear violent objections, I was also planning
> to provide the additional variant that was discussed:
>
> with(boolean returning, Closure closure)
>
> so folks could use with(true) if they wanted. It's a little clunky but
> is the kind of thing we do in other places within Groovy, provides an
> alternative for anyone that finds 'tap' totally foreign and might also
> help steer users between the two related methods.
>
> Cheers, Paul.
>
>
> On Thu, Nov 10, 2016 at 3:04 PM, Paul King <pa...@asert.com.au> wrote:
> > On Thu, Nov 10, 2016 at 6:45 AM, Jordan Martinez
> > <jo...@gmail.com> wrote:
> >> What about `object.itselfWith(Closure)`? Then its understood as
> returning
> >> the object itself but with the changes that follow.
> >
> > Both variants use 'itself' but only one returns 'itself', so I would
> > regard that prefix as not distinguishing enough. You'd need something
> > like 'withThen' or 'withReturning' to help distinguish between the
> > two. The problem with 'withReturning' is that it is longer
> > (character-wise) than 'with(true)' or just adding 'return it' or 'it'
> > to the end of the closure - not that numbers of characters alone
> > should be the most important metric.
> >
> > Cheers, Paul.
>



-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

Ok, disussion seems to have finished on this topic. I was planning to
merge Christoph's PR with minor tweaks as needed. I was going to use
'tap' as the name.

At this stage, unless I hear violent objections, I was also planning
to provide the additional variant that was discussed:

with(boolean returning, Closure closure)

so folks could use with(true) if they wanted. It's a little clunky but
is the kind of thing we do in other places within Groovy, provides an
alternative for anyone that finds 'tap' totally foreign and might also
help steer users between the two related methods.

Cheers, Paul.


On Thu, Nov 10, 2016 at 3:04 PM, Paul King <pa...@asert.com.au> wrote:
> On Thu, Nov 10, 2016 at 6:45 AM, Jordan Martinez
> <jo...@gmail.com> wrote:
>> What about `object.itselfWith(Closure)`? Then its understood as returning
>> the object itself but with the changes that follow.
>
> Both variants use 'itself' but only one returns 'itself', so I would
> regard that prefix as not distinguishing enough. You'd need something
> like 'withThen' or 'withReturning' to help distinguish between the
> two. The problem with 'withReturning' is that it is longer
> (character-wise) than 'with(true)' or just adding 'return it' or 'it'
> to the end of the closure - not that numbers of characters alone
> should be the most important metric.
>
> Cheers, Paul.

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

On Thu, Nov 10, 2016 at 6:45 AM, Jordan Martinez
<jo...@gmail.com> wrote:
> What about `object.itselfWith(Closure)`? Then its understood as returning
> the object itself but with the changes that follow.

Both variants use 'itself' but only one returns 'itself', so I would
regard that prefix as not distinguishing enough. You'd need something
like 'withThen' or 'withReturning' to help distinguish between the
two. The problem with 'withReturning' is that it is longer
(character-wise) than 'with(true)' or just adding 'return it' or 'it'
to the end of the closure - not that numbers of characters alone
should be the most important metric.

Cheers, Paul.

Re: .with() variant that returns the original object

[Jordan Martinez <jo...@gmail.com>]

What about `object.itselfWith(Closure)`? Then its understood as returning
the object itself but with the changes that follow.

Blessings,
Jordan

On Wed, Nov 9, 2016 at 12:32 PM, Paul King <pa...@asert.com.au> wrote:

> On Thu, Nov 10, 2016 at 12:02 AM, Cédric Champeau
> <ce...@gmail.com> wrote:
> > I agree with what Jason said. I'm still up for `tap`. We could use
> > `with(true) { ... }`, but I also dislike "with(returnThis: true) {... }"
> > because it's not type safe.
>
> If we progress GROOVY-7956, we'd have type safety but I agree with you
> anyway. And it should be returnImplicitThis or returnSelf or something
> anyway.
>
> Cheers, Paul.
>

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

On Thu, Nov 10, 2016 at 12:02 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> I agree with what Jason said. I'm still up for `tap`. We could use
> `with(true) { ... }`, but I also dislike "with(returnThis: true) {... }"
> because it's not type safe.

If we progress GROOVY-7956, we'd have type safety but I agree with you
anyway. And it should be returnImplicitThis or returnSelf or something
anyway.

Cheers, Paul.

Re: .with() variant that returns the original object

[Cédric Champeau <ce...@gmail.com>]

I agree with what Jason said. I'm still up for `tap`. We could use
`with(true) { ... }`, but I also dislike "with(returnThis: true) {... }"
because it's not type safe.



2016-11-09 14:56 GMT+01:00 Winnebeck, Jason <Ja...@windstream.com>
:

> My concern about "withThis" is that it implies that "this" is the
> parameter of the closure and not the return. We have for example
> withReader, withWriter, withOutputStream, etc. Those all imply that the
> parameter is the reader, the writer, the output stream. So in my mind,
> withThis tells me nothing at all about the fact that the original object is
> returned. withThis would not be consistent with the rest of Groovy.
>
> .with(returnThis:true) not only has runtime overhead, but keep in mind we
> are comparing this to the current state today, which is .with { return this
> }, or .with { this } depending on your style. So anything we pick needs to
> be shorter or more obvious than that, if not, then we should do nothing and
> just tell people to end the closure with "return this", or even just
> "this". That's why I would vote against .withReturnThis or
> .with(returnThis:true), or the equally cryptic .with(true).
>
> Jason Winnebeck
>
> -----Original Message-----
> From: Philip Mitchell [mailto:pjmitchell@blueyonder.co.uk]
> Sent: Tuesday, November 08, 2016 7:53 PM
> To: users@groovy.apache.org; paulk@asert.com.au
> Subject: Re: .with() variant that returns the original object
>
> +1 for withThis()
> -1 tap()
>
> I agree with the point below. Given this is virtually identical to the
> existing with() method, the new methods name should reflect that.
> Consistency within Groovy and it’s existing libraries counts for more than
> consistency with what the method is called in another language.
>
> I see comments below that tap() makes more sense once explained, but I
> would argue that the fact it needs explained is enough of a reason to
> reject it. I lean toward method names that clearly express what they do.
> tap() seem cryptic. The name withThis() has the virtue of being reasonably
> descriptive as well as being consistent with the existing with() method
> name.
>
> Just my 2-cents worth.
>
> Phil Mitchell
>
>
> > On 8 Nov 2016, at 23:49, Paul King <pa...@asert.com.au> wrote:
> >
> > Well we certainly could have as per Jochen's suggestion a DGM method
> > roughly like:
> >
> > public static with(def self, boolean returnThis, Closure closure) {
> > ... }
> >
> > and for backwards compatibility returnThis would default to false,
> > i.e. with(closure) and identity(closure) are an alias for with(false,
> > closure) and tap would be an alias for with(true, closure)
> >
> > I think it is worth having the alias, if nothing else for better type
> > inferencing we'll get from the signatures but also letting people
> > choose between tap and with(true).
> >
> > Cheers, Paul.
> >
> >
> > On Wed, Nov 9, 2016 at 9:02 AM, Henrik Martin <he...@netgate.net>
> wrote:
> >> +1 for withThis or withValue and +10 for Jochen's overloading
> >> +proposal if
> >> it's feasible.
> >> -1000 for tap. Completely nonsensical to me and makes me think of
> >> network tun/tap interfaces in Linux or something like that. Isn't the
> >> functionality a little bit like the Builder pattern more than a
> pipeline of commands?
> >> Maybe I'm misunderstanding the whole thing. Either way, to introduce
> >> a completely new name for something that is already named and simply
> >> augmented in terms of functionality seems very confusing and counter
> intuitive to me.
> >> Imagine a Groovy newbie that reads a tutorial or reference manual and
> >> first learns about with(). Then a little further on, tap() is
> >> introduced. I would immediately think "why on earth did they name
> >> these things completely differently, when one is essentially a
> >> variant of the other???". Again, forgive me if I'm completely
> misunderstanding the context here.
> >>
> >> -Henrik
> >>
> >> On 11/8/16 10:16 AM, Gerald Wiltse wrote:
> >>
> >> Some really neat and creative suggestions here suddenly. Still happy
> >> with any name, but I do like "withThis"  and "having",  However, tap
> >> seems to be gaining momentum and with good reasons, despite the
> >> common complaint of "What the heck does tap mean".  I agree it makes
> more sense after explained.
> >>
> >> Gerald R. Wiltse
> >> jerrywiltse@gmail.com
> >>
> >>
> >> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <ma...@mac.com> wrote:
> >>>
> >>> +1 for tap.  Concise and makes sense once explained (even intuitive
> >>> +to
> >>> some).
> >>>
> >>> Have you ever tried to find usages of with in groovy with code
> >>> examples with google without eventually loosing your temper ?
> >>>
> >>> For one thing, I think tap will be easier to google for.
> >>>
> >>> Marc Paquette
> >>>
> >>> Le 8 nov. 2016 à 12:32, Suderman Keith <su...@anc.org> a écrit :
> >>>
> >>>
> >>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <bl...@gmx.org>
> wrote:
> >>>
> >>> what about an overloaded with:
> >>>
> >>>
> >>> +1
> >>>
> >>> Or even something like:
> >>>
> >>> myObject.with { ... } // current behaviour
> >>> myObject.with(return:this) { ... } // returns this when finished.
> >>> myObejct.with(return:new Object()) { ... } // returns a new Object
> >>> when finished.
> >>>
> >>> This particular syntax would take a bit of extra parser arm waving
> >>> since the `return` keyword is being used differently in this context.
> >>>
> >>> Keith
> >>>
> >>>
> >>> myObject.with(true) {
> >>>  // some code
> >>> }
> >>>
> >>>
> >>> or:
> >>>
> >>> myObject.with(returnThis:true) {
> >>>  // some code
> >>> }
> >>>
> >>>
> >>> or... well I am sure there are many variants... just want to know if
> >>> something like this doesn't cut it.
> >>>
> >>> bye Jochen
> >>>
> >>>
> >>>
> >>
> >>
>
>
> This email message and any attachments are for the sole use of the
> intended recipient(s). Any unauthorized review, use, disclosure or
> distribution is prohibited. If you are not the intended recipient, please
> contact the sender by reply email and destroy all copies of the original
> message and any attachments.
>

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

Yes, there are no plans to break backwards compatibility, it's very
handy to be able to do:

def fullName = person.with{ "$firstName $lastName" }

We wouldn't want code like that to break.

Cheers, Paul.

On Thu, Nov 10, 2016 at 7:02 AM, Winnebeck, Jason
<Ja...@windstream.com> wrote:
> Regarding Jochen's
> Please don't change the existing behavior of with, that was mentioned once before, and it breaks backwards compatibility. I use it extensively in DSL code, here is a fictional DSL example that is similar in what I use it for:
>
> def peopleWhere(Closure c) { people.findAll { it.with(c) } }
>
> def younglings = peopleWhere { age < 35 }
>
> In this example, I use with to avoid the extra boilerplate of cloning the closure and setting resolve strategy, delegate, and calling it.
>
> Jason
>
> -----Original Message-----
> From: Jochen Theodorou [mailto:blackdrag@gmx.org]
> Sent: Wednesday, November 09, 2016 1:45 PM
> To: users@groovy.apache.org
> Subject: Re: .with() variant that returns the original object
>
> On 09.11.2016 14:56, Winnebeck, Jason wrote:
>> My concern about "withThis" is that it implies that "this" is the parameter of the closure and not the return. We have for example withReader, withWriter, withOutputStream, etc. Those all imply that the parameter is the reader, the writer, the output stream. So in my mind, withThis tells me nothing at all about the fact that the original object is returned. withThis would not be consistent with the rest of Groovy.
>
> I agree with this one.
>
>> .with(returnThis:true) not only has runtime overhead, but keep in mind we are comparing this to the current state today, which is .with { return this }, or .with { this } depending on your style.
>
> here I have to correct a bit though. Just want to avoid we start discussing the wrong thing... And I just noticed Paul made the very same mistake in the original post already. Well, maybe not too late yet
>
> we are talking about
>
> foo.with {
>    return foo
> }
>
> or
>
> foo.with {
>   return it
> }
>
> not about something returning "this" at any point. "return this" would return neither the open block, nor foo, it would be the enclosing class instance. No delegate has influence about any explicit this ever.
>
> Ah, and I did just see Jason noticed it in a later mail... well, maybe saying it two times is better ;)
>
> Anyway, that´s why I think withThis and with(returnThis:true) are not good variants.
>
> Also it should be noted that we already have an alias for "with", which is "identity". I would not want to have yet another one.
>
> Frankly... I think we should change what it returns. It is unlikely somebody did depend on with returning null.
>
> bye Jochen
>
> This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

RE: .with() variant that returns the original object

["Winnebeck, Jason" <Ja...@windstream.com>]

Regarding Jochen's 
Please don't change the existing behavior of with, that was mentioned once before, and it breaks backwards compatibility. I use it extensively in DSL code, here is a fictional DSL example that is similar in what I use it for:

def peopleWhere(Closure c) { people.findAll { it.with(c) } }

def younglings = peopleWhere { age < 35 }

In this example, I use with to avoid the extra boilerplate of cloning the closure and setting resolve strategy, delegate, and calling it.

Jason

-----Original Message-----
From: Jochen Theodorou [mailto:blackdrag@gmx.org] 
Sent: Wednesday, November 09, 2016 1:45 PM
To: users@groovy.apache.org
Subject: Re: .with() variant that returns the original object

On 09.11.2016 14:56, Winnebeck, Jason wrote:
> My concern about "withThis" is that it implies that "this" is the parameter of the closure and not the return. We have for example withReader, withWriter, withOutputStream, etc. Those all imply that the parameter is the reader, the writer, the output stream. So in my mind, withThis tells me nothing at all about the fact that the original object is returned. withThis would not be consistent with the rest of Groovy.

I agree with this one.

> .with(returnThis:true) not only has runtime overhead, but keep in mind we are comparing this to the current state today, which is .with { return this }, or .with { this } depending on your style.

here I have to correct a bit though. Just want to avoid we start discussing the wrong thing... And I just noticed Paul made the very same mistake in the original post already. Well, maybe not too late yet

we are talking about

foo.with {
   return foo
}

or

foo.with {
  return it
}

not about something returning "this" at any point. "return this" would return neither the open block, nor foo, it would be the enclosing class instance. No delegate has influence about any explicit this ever.

Ah, and I did just see Jason noticed it in a later mail... well, maybe saying it two times is better ;)

Anyway, that´s why I think withThis and with(returnThis:true) are not good variants.

Also it should be noted that we already have an alias for "with", which is "identity". I would not want to have yet another one.

Frankly... I think we should change what it returns. It is unlikely somebody did depend on with returning null.

bye Jochen

This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

On Thu, Nov 10, 2016 at 4:44 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> ... And I just noticed Paul made the very same mistake in the original post already.

Ah yes, it should be return it or return "implicitThis" not return this.

Cheers, Paul.

Re: .with() variant that returns the original object

["Søren Berg Glasius (GR8Conf EU)" <sb...@gr8conf.org>]

I know, that I depend on a with{} returning what I make it return, so
making it return null or another value would be bad.

Best regards,
Søren Berg Glasius
GR8Conf Europe organizing team

GR8Conf ApS
Mobile: +45 40 44 91 88, Web: www.gr8conf.eu, Skype: sbglasius
Company Address: Buchwaldsgade 50, 5000 Odense C, Denmark
Personal Address: Hedevej 1, Gl. Rye, 8680 Ry, Denmark
--- GR8Conf - Dedicated to the Groovy Ecosystem

From: OC <oc...@ocs.cz> <oc...@ocs.cz>
Reply: users@groovy.apache.org <us...@groovy.apache.org>
<us...@groovy.apache.org>
Date: 9. november 2016 at 20.33.17
To: users@groovy.apache.org <us...@groovy.apache.org>
<us...@groovy.apache.org>, Jochen Theodorou <bl...@gmx.org>
<bl...@gmx.org>
Subject:  Re: .with() variant that returns the original object

Jochen,

On 9. 11. 2016, at 19:44, Jochen Theodorou <bl...@gmx.org> wrote:
...
> Also it should be noted that we already have an alias for "with", which
is "identity". I would not want to have yet another one.
> Frankly... I think we should change what it returns.

whilst I agree too many aliases is a bad thing, in my personal opinion,
breaking backward compatibility is worse.

> It is unlikely somebody did depend on with returning null.

I might be wrong as so often, but I can well imagine somebody depends on
the current behaviour, which, far as I understand, is not returning null,
but returning the result of the last expression in the closure -- precisely
what I would myself like to be available in future as "resultWith".

All the best,
OC

Re: .with() variant that returns the original object

[OC <oc...@ocs.cz>]

Jochen,

On 9. 11. 2016, at 19:44, Jochen Theodorou <bl...@gmx.org> wrote:
...
> Also it should be noted that we already have an alias for "with", which is "identity". I would not want to have yet another one.
> Frankly... I think we should change what it returns.

whilst I agree too many aliases is a bad thing, in my personal opinion, breaking backward compatibility is worse.

> It is unlikely somebody did depend on with returning null.

I might be wrong as so often, but I can well imagine somebody depends on the current behaviour, which, far as I understand, is not returning null, but returning the result of the last expression in the closure -- precisely what I would myself like to be available in future as "resultWith".

All the best,
OC

Re: .with() variant that returns the original object

[Jochen Theodorou <bl...@gmx.org>]

On 09.11.2016 14:56, Winnebeck, Jason wrote:
> My concern about "withThis" is that it implies that "this" is the parameter of the closure and not the return. We have for example withReader, withWriter, withOutputStream, etc. Those all imply that the parameter is the reader, the writer, the output stream. So in my mind, withThis tells me nothing at all about the fact that the original object is returned. withThis would not be consistent with the rest of Groovy.

I agree with this one.

> .with(returnThis:true) not only has runtime overhead, but keep in mind we are comparing this to the current state today, which is .with { return this }, or .with { this } depending on your style.

here I have to correct a bit though. Just want to avoid we start 
discussing the wrong thing... And I just noticed Paul made the very same 
mistake in the original post already. Well, maybe not too late yet

we are talking about

foo.with {
   return foo
}

or

foo.with {
  return it
}

not about something returning "this" at any point. "return this" would 
return neither the open block, nor foo, it would be the enclosing class 
instance. No delegate has influence about any explicit this ever.

Ah, and I did just see Jason noticed it in a later mail... well, maybe 
saying it two times is better ;)

Anyway, that�s why I think withThis and with(returnThis:true) are not 
good variants.

Also it should be noted that we already have an alias for "with", which 
is "identity". I would not want to have yet another one.

Frankly... I think we should change what it returns. It is unlikely 
somebody did depend on with returning null.

bye Jochen

RE: .with() variant that returns the original object

["Winnebeck, Jason" <Ja...@windstream.com>]

My concern about "withThis" is that it implies that "this" is the parameter of the closure and not the return. We have for example withReader, withWriter, withOutputStream, etc. Those all imply that the parameter is the reader, the writer, the output stream. So in my mind, withThis tells me nothing at all about the fact that the original object is returned. withThis would not be consistent with the rest of Groovy.

.with(returnThis:true) not only has runtime overhead, but keep in mind we are comparing this to the current state today, which is .with { return this }, or .with { this } depending on your style. So anything we pick needs to be shorter or more obvious than that, if not, then we should do nothing and just tell people to end the closure with "return this", or even just "this". That's why I would vote against .withReturnThis or .with(returnThis:true), or the equally cryptic .with(true).

Jason Winnebeck

-----Original Message-----
From: Philip Mitchell [mailto:pjmitchell@blueyonder.co.uk] 
Sent: Tuesday, November 08, 2016 7:53 PM
To: users@groovy.apache.org; paulk@asert.com.au
Subject: Re: .with() variant that returns the original object

+1 for withThis()
-1 tap()

I agree with the point below. Given this is virtually identical to the existing with() method, the new methods name should reflect that. Consistency within Groovy and it’s existing libraries counts for more than consistency with what the method is called in another language.

I see comments below that tap() makes more sense once explained, but I would argue that the fact it needs explained is enough of a reason to reject it. I lean toward method names that clearly express what they do. tap() seem cryptic. The name withThis() has the virtue of being reasonably descriptive as well as being consistent with the existing with() method name. 

Just my 2-cents worth.

Phil Mitchell


> On 8 Nov 2016, at 23:49, Paul King <pa...@asert.com.au> wrote:
> 
> Well we certainly could have as per Jochen's suggestion a DGM method 
> roughly like:
> 
> public static with(def self, boolean returnThis, Closure closure) { 
> ... }
> 
> and for backwards compatibility returnThis would default to false, 
> i.e. with(closure) and identity(closure) are an alias for with(false, 
> closure) and tap would be an alias for with(true, closure)
> 
> I think it is worth having the alias, if nothing else for better type 
> inferencing we'll get from the signatures but also letting people 
> choose between tap and with(true).
> 
> Cheers, Paul.
> 
> 
> On Wed, Nov 9, 2016 at 9:02 AM, Henrik Martin <he...@netgate.net> wrote:
>> +1 for withThis or withValue and +10 for Jochen's overloading 
>> +proposal if
>> it's feasible.
>> -1000 for tap. Completely nonsensical to me and makes me think of 
>> network tun/tap interfaces in Linux or something like that. Isn't the 
>> functionality a little bit like the Builder pattern more than a pipeline of commands?
>> Maybe I'm misunderstanding the whole thing. Either way, to introduce 
>> a completely new name for something that is already named and simply 
>> augmented in terms of functionality seems very confusing and counter intuitive to me.
>> Imagine a Groovy newbie that reads a tutorial or reference manual and 
>> first learns about with(). Then a little further on, tap() is 
>> introduced. I would immediately think "why on earth did they name 
>> these things completely differently, when one is essentially a 
>> variant of the other???". Again, forgive me if I'm completely misunderstanding the context here.
>> 
>> -Henrik
>> 
>> On 11/8/16 10:16 AM, Gerald Wiltse wrote:
>> 
>> Some really neat and creative suggestions here suddenly. Still happy 
>> with any name, but I do like "withThis"  and "having",  However, tap 
>> seems to be gaining momentum and with good reasons, despite the 
>> common complaint of "What the heck does tap mean".  I agree it makes more sense after explained.
>> 
>> Gerald R. Wiltse
>> jerrywiltse@gmail.com
>> 
>> 
>> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <ma...@mac.com> wrote:
>>> 
>>> +1 for tap.  Concise and makes sense once explained (even intuitive 
>>> +to
>>> some).
>>> 
>>> Have you ever tried to find usages of with in groovy with code 
>>> examples with google without eventually loosing your temper ?
>>> 
>>> For one thing, I think tap will be easier to google for.
>>> 
>>> Marc Paquette
>>> 
>>> Le 8 nov. 2016 à 12:32, Suderman Keith <su...@anc.org> a écrit :
>>> 
>>> 
>>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>>> 
>>> what about an overloaded with:
>>> 
>>> 
>>> +1
>>> 
>>> Or even something like:
>>> 
>>> myObject.with { ... } // current behaviour
>>> myObject.with(return:this) { ... } // returns this when finished.
>>> myObejct.with(return:new Object()) { ... } // returns a new Object 
>>> when finished.
>>> 
>>> This particular syntax would take a bit of extra parser arm waving 
>>> since the `return` keyword is being used differently in this context.
>>> 
>>> Keith
>>> 
>>> 
>>> myObject.with(true) {
>>>  // some code
>>> }
>>> 
>>> 
>>> or:
>>> 
>>> myObject.with(returnThis:true) {
>>>  // some code
>>> }
>>> 
>>> 
>>> or... well I am sure there are many variants... just want to know if 
>>> something like this doesn't cut it.
>>> 
>>> bye Jochen
>>> 
>>> 
>>> 
>> 
>> 


This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

Re: .with() variant that returns the original object

[Felix Dorner <fe...@gmail.com>]

What about a syntax for closures that return 'this' implicitly?

On Wed, Nov 9, 2016 at 2:57 AM, ocs@ocs.cz <oc...@ocs.cz> wrote:

> Paul,
>
> > On 9. 11. 2016, at 2:43 AM, Paul King <pa...@asert.com.au> wrote:
> > Everything you say is true but withThis() has some subtle issues.
> > It would be a fine name for the current with() method, so it's hard to
> > distinguish between the two.
>
> That's why I have suggested to part with the original one (but for
> backward compatibility) and take two new methods,
>
> foo.doWith { ... } // which returns foo, which seems sorta logical
> foo.resultWith { ... } // which returns the result of the closure and is
> worlds more intuitive that the original one
>
> or am I overlooking something of importance?
>
> All the best,
> OC
>
> > Using self.with(closure) sets self to be the delegate of the closure
> > which effectively means it becomes the "implicit this" object.
> > So conceptually a shorthand for self.withSelfAsTheImplicitThisObjec
> t(closure).
> > The new method needs to be a shorthand for
> > self.withSelfAsTheImplicitThisObjectThenReturningSelf(closure).
> > So when picking the shorthand, we should derive something about the
> > dirrerence between these two names in the shortcut and "This" is one
> > of the similarities.
> > I'd prefer "withThen".
> >
> > Also, the link with tap and Ruby isn't about trying to be like Ruby
> > but about not introducing yet another name for something that is in
> > use elsewhere *unless* we have a good reason.
> >
> > Cheers, Paul.
> >
> > On Wed, Nov 9, 2016 at 10:53 AM, Philip Mitchell
> > <pj...@blueyonder.co.uk> wrote:
> >> +1 for withThis()
> >> -1 tap()
> >>
> >> I agree with the point below. Given this is virtually identical to the
> existing with() method, the new methods name should reflect that.
> Consistency within Groovy and it’s existing libraries counts for more than
> consistency with what the method is called in another language.
> >>
> >> I see comments below that tap() makes more sense once explained, but I
> would argue that the fact it needs explained is enough of a reason to
> reject it. I lean toward method names that clearly express what they do.
> tap() seem cryptic. The name withThis() has the virtue of being reasonably
> descriptive as well as being consistent with the existing with() method
> name.
> >>
> >> Just my 2-cents worth.
> >>
> >> Phil Mitchell
>
>


-- 
Linux. The choice of a GNU generation.

Re: .with() variant that returns the original object

["ocs@ocs.cz" <oc...@ocs.cz>]

Paul,

> On 9. 11. 2016, at 2:43 AM, Paul King <pa...@asert.com.au> wrote:
> Everything you say is true but withThis() has some subtle issues.
> It would be a fine name for the current with() method, so it's hard to
> distinguish between the two.

That's why I have suggested to part with the original one (but for backward compatibility) and take two new methods,

foo.doWith { ... } // which returns foo, which seems sorta logical
foo.resultWith { ... } // which returns the result of the closure and is worlds more intuitive that the original one

or am I overlooking something of importance?

All the best,
OC

> Using self.with(closure) sets self to be the delegate of the closure
> which effectively means it becomes the "implicit this" object.
> So conceptually a shorthand for self.withSelfAsTheImplicitThisObject(closure).
> The new method needs to be a shorthand for
> self.withSelfAsTheImplicitThisObjectThenReturningSelf(closure).
> So when picking the shorthand, we should derive something about the
> dirrerence between these two names in the shortcut and "This" is one
> of the similarities.
> I'd prefer "withThen".
> 
> Also, the link with tap and Ruby isn't about trying to be like Ruby
> but about not introducing yet another name for something that is in
> use elsewhere *unless* we have a good reason.
> 
> Cheers, Paul.
> 
> On Wed, Nov 9, 2016 at 10:53 AM, Philip Mitchell
> <pj...@blueyonder.co.uk> wrote:
>> +1 for withThis()
>> -1 tap()
>> 
>> I agree with the point below. Given this is virtually identical to the existing with() method, the new methods name should reflect that. Consistency within Groovy and it’s existing libraries counts for more than consistency with what the method is called in another language.
>> 
>> I see comments below that tap() makes more sense once explained, but I would argue that the fact it needs explained is enough of a reason to reject it. I lean toward method names that clearly express what they do. tap() seem cryptic. The name withThis() has the virtue of being reasonably descriptive as well as being consistent with the existing with() method name.
>> 
>> Just my 2-cents worth.
>> 
>> Phil Mitchell

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

Hi Phil,

Everything you say is true but withThis() has some subtle issues.
It would be a fine name for the current with() method, so it's hard to
distinguish between the two.
Using self.with(closure) sets self to be the delegate of the closure
which effectively means it becomes the "implicit this" object.
So conceptually a shorthand for self.withSelfAsTheImplicitThisObject(closure).
The new method needs to be a shorthand for
self.withSelfAsTheImplicitThisObjectThenReturningSelf(closure).
So when picking the shorthand, we should derive something about the
dirrerence between these two names in the shortcut and "This" is one
of the similarities.
I'd prefer "withThen".

Also, the link with tap and Ruby isn't about trying to be like Ruby
but about not introducing yet another name for something that is in
use elsewhere *unless* we have a good reason.

Cheers, Paul.

On Wed, Nov 9, 2016 at 10:53 AM, Philip Mitchell
<pj...@blueyonder.co.uk> wrote:
> +1 for withThis()
> -1 tap()
>
> I agree with the point below. Given this is virtually identical to the existing with() method, the new methods name should reflect that. Consistency within Groovy and it’s existing libraries counts for more than consistency with what the method is called in another language.
>
> I see comments below that tap() makes more sense once explained, but I would argue that the fact it needs explained is enough of a reason to reject it. I lean toward method names that clearly express what they do. tap() seem cryptic. The name withThis() has the virtue of being reasonably descriptive as well as being consistent with the existing with() method name.
>
> Just my 2-cents worth.
>
> Phil Mitchell

Re: .with() variant that returns the original object

[Philip Mitchell <pj...@blueyonder.co.uk>]

+1 for withThis()
-1 tap()

I agree with the point below. Given this is virtually identical to the existing with() method, the new methods name should reflect that. Consistency within Groovy and it’s existing libraries counts for more than consistency with what the method is called in another language.

I see comments below that tap() makes more sense once explained, but I would argue that the fact it needs explained is enough of a reason to reject it. I lean toward method names that clearly express what they do. tap() seem cryptic. The name withThis() has the virtue of being reasonably descriptive as well as being consistent with the existing with() method name. 

Just my 2-cents worth.

Phil Mitchell


> On 8 Nov 2016, at 23:49, Paul King <pa...@asert.com.au> wrote:
> 
> Well we certainly could have as per Jochen's suggestion a DGM method
> roughly like:
> 
> public static with(def self, boolean returnThis, Closure closure) { ... }
> 
> and for backwards compatibility returnThis would default to false,
> i.e. with(closure) and identity(closure) are an alias for with(false, closure)
> and tap would be an alias for with(true, closure)
> 
> I think it is worth having the alias, if nothing else for better type
> inferencing we'll get from the signatures but also letting people
> choose between tap and with(true).
> 
> Cheers, Paul.
> 
> 
> On Wed, Nov 9, 2016 at 9:02 AM, Henrik Martin <he...@netgate.net> wrote:
>> +1 for withThis or withValue and +10 for Jochen's overloading proposal if
>> it's feasible.
>> -1000 for tap. Completely nonsensical to me and makes me think of network
>> tun/tap interfaces in Linux or something like that. Isn't the functionality
>> a little bit like the Builder pattern more than a pipeline of commands?
>> Maybe I'm misunderstanding the whole thing. Either way, to introduce a
>> completely new name for something that is already named and simply augmented
>> in terms of functionality seems very confusing and counter intuitive to me.
>> Imagine a Groovy newbie that reads a tutorial or reference manual and first
>> learns about with(). Then a little further on, tap() is introduced. I would
>> immediately think "why on earth did they name these things completely
>> differently, when one is essentially a variant of the other???". Again,
>> forgive me if I'm completely misunderstanding the context here.
>> 
>> -Henrik
>> 
>> On 11/8/16 10:16 AM, Gerald Wiltse wrote:
>> 
>> Some really neat and creative suggestions here suddenly. Still happy with
>> any name, but I do like "withThis"  and "having",  However, tap seems to be
>> gaining momentum and with good reasons, despite the common complaint of
>> "What the heck does tap mean".  I agree it makes more sense after explained.
>> 
>> Gerald R. Wiltse
>> jerrywiltse@gmail.com
>> 
>> 
>> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <ma...@mac.com> wrote:
>>> 
>>> +1 for tap.  Concise and makes sense once explained (even intuitive to
>>> some).
>>> 
>>> Have you ever tried to find usages of with in groovy with code examples
>>> with google without eventually loosing your temper ?
>>> 
>>> For one thing, I think tap will be easier to google for.
>>> 
>>> Marc Paquette
>>> 
>>> Le 8 nov. 2016 à 12:32, Suderman Keith <su...@anc.org> a écrit :
>>> 
>>> 
>>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>>> 
>>> what about an overloaded with:
>>> 
>>> 
>>> +1
>>> 
>>> Or even something like:
>>> 
>>> myObject.with { ... } // current behaviour
>>> myObject.with(return:this) { ... } // returns this when finished.
>>> myObejct.with(return:new Object()) { ... } // returns a new Object when
>>> finished.
>>> 
>>> This particular syntax would take a bit of extra parser arm waving since
>>> the `return` keyword is being used differently in this context.
>>> 
>>> Keith
>>> 
>>> 
>>> myObject.with(true) {
>>>  // some code
>>> }
>>> 
>>> 
>>> or:
>>> 
>>> myObject.with(returnThis:true) {
>>>  // some code
>>> }
>>> 
>>> 
>>> or... well I am sure there are many variants... just want to know if
>>> something like this doesn't cut it.
>>> 
>>> bye Jochen
>>> 
>>> 
>>> 
>> 
>> 

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

Well we certainly could have as per Jochen's suggestion a DGM method
roughly like:

public static with(def self, boolean returnThis, Closure closure) { ... }

and for backwards compatibility returnThis would default to false,
i.e. with(closure) and identity(closure) are an alias for with(false, closure)
and tap would be an alias for with(true, closure)

I think it is worth having the alias, if nothing else for better type
inferencing we'll get from the signatures but also letting people
choose between tap and with(true).

Cheers, Paul.


On Wed, Nov 9, 2016 at 9:02 AM, Henrik Martin <he...@netgate.net> wrote:
> +1 for withThis or withValue and +10 for Jochen's overloading proposal if
> it's feasible.
> -1000 for tap. Completely nonsensical to me and makes me think of network
> tun/tap interfaces in Linux or something like that. Isn't the functionality
> a little bit like the Builder pattern more than a pipeline of commands?
> Maybe I'm misunderstanding the whole thing. Either way, to introduce a
> completely new name for something that is already named and simply augmented
> in terms of functionality seems very confusing and counter intuitive to me.
> Imagine a Groovy newbie that reads a tutorial or reference manual and first
> learns about with(). Then a little further on, tap() is introduced. I would
> immediately think "why on earth did they name these things completely
> differently, when one is essentially a variant of the other???". Again,
> forgive me if I'm completely misunderstanding the context here.
>
> -Henrik
>
> On 11/8/16 10:16 AM, Gerald Wiltse wrote:
>
> Some really neat and creative suggestions here suddenly. Still happy with
> any name, but I do like "withThis"  and "having",  However, tap seems to be
> gaining momentum and with good reasons, despite the common complaint of
> "What the heck does tap mean".  I agree it makes more sense after explained.
>
> Gerald R. Wiltse
> jerrywiltse@gmail.com
>
>
> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <ma...@mac.com> wrote:
>>
>> +1 for tap.  Concise and makes sense once explained (even intuitive to
>> some).
>>
>> Have you ever tried to find usages of with in groovy with code examples
>> with google without eventually loosing your temper ?
>>
>> For one thing, I think tap will be easier to google for.
>>
>> Marc Paquette
>>
>> Le 8 nov. 2016 à 12:32, Suderman Keith <su...@anc.org> a écrit :
>>
>>
>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>>
>> what about an overloaded with:
>>
>>
>> +1
>>
>> Or even something like:
>>
>> myObject.with { ... } // current behaviour
>> myObject.with(return:this) { ... } // returns this when finished.
>> myObejct.with(return:new Object()) { ... } // returns a new Object when
>> finished.
>>
>> This particular syntax would take a bit of extra parser arm waving since
>> the `return` keyword is being used differently in this context.
>>
>> Keith
>>
>>
>> myObject.with(true) {
>>   // some code
>> }
>>
>>
>> or:
>>
>> myObject.with(returnThis:true) {
>>   // some code
>> }
>>
>>
>> or... well I am sure there are many variants... just want to know if
>> something like this doesn't cut it.
>>
>> bye Jochen
>>
>>
>>
>
>

Re: .with() variant that returns the original object

[Henrik Martin <he...@netgate.net>]

+1 for withThis or withValue and +10 for Jochen's overloading proposal 
if it's feasible.
-1000 for tap. Completely nonsensical to me and makes me think of 
network tun/tap interfaces in Linux or something like that. Isn't the 
functionality a little bit like the Builder pattern more than a pipeline 
of commands? Maybe I'm misunderstanding the whole thing. Either way, to 
introduce a completely new name for something that is already named and 
simply augmented in terms of functionality seems very confusing and 
counter intuitive to me. Imagine a Groovy newbie that reads a tutorial 
or reference manual and first learns about with(). Then a little further 
on, tap() is introduced. I would immediately think "why on earth did 
they name these things completely differently, when one is essentially a 
variant of the other???". Again, forgive me if I'm completely 
misunderstanding the context here.

-Henrik

On 11/8/16 10:16 AM, Gerald Wiltse wrote:
> Some really neat and creative suggestions here suddenly. Still happy 
> with any name, but I do like "withThis"  and "having",  However, tap 
> seems to be gaining momentum and with good reasons, despite the common 
> complaint of "What the heck does tap mean".  I agree it makes more 
> sense after explained.
>
> Gerald R. Wiltse
> jerrywiltse@gmail.com <ma...@gmail.com>
>
>
> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <marcpa@mac.com 
> <ma...@mac.com>> wrote:
>
>     +1 for tap.  Concise and makes sense once explained (even
>     intuitive to some).
>
>     Have you ever tried to find usages of with in groovy with code
>     examples with google without eventually loosing your temper ?
>
>     For one thing, I think tap will be easier to google for.
>
>     Marc Paquette
>
>>     Le 8 nov. 2016 � 12:32, Suderman Keith <suderman@anc.org
>>     <ma...@anc.org>> a �crit :
>>
>>
>>>     On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <blackdrag@gmx.org
>>>     <ma...@gmx.org>> wrote:
>>>
>>>     what about an overloaded with:
>>
>>     +1
>>
>>     Or even something like:
>>
>>     myObject.with { ... } // current behaviour
>>     myObject.with(return:this) { ... } // returns this when finished.
>>     myObejct.with(return:new Object()) { ... } // returns a new
>>     Object when finished.
>>
>>     This particular syntax would take a bit of extra parser arm
>>     waving since the `return` keyword is being used differently in
>>     this context.
>>
>>     Keith
>>
>>>
>>>>>     myObject.with(true) {
>>>>>       // some code
>>>>>     }
>>>
>>>     or:
>>>
>>>>>     myObject.with(returnThis:true) {
>>>>>       // some code
>>>>>     }
>>>
>>>     or... well I am sure there are many variants... just want to
>>>     know if something like this doesn't cut it.
>>>
>>>     bye Jochen
>>
>
>

Re: .with() variant that returns the original object

[Gerald Wiltse <je...@gmail.com>]

Some really neat and creative suggestions here suddenly. Still happy with
any name, but I do like "withThis"  and "having",  However, tap seems to be
gaining momentum and with good reasons, despite the common complaint of
"What the heck does tap mean".  I agree it makes more sense after
explained.

Gerald R. Wiltse
jerrywiltse@gmail.com


On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <ma...@mac.com> wrote:

> +1 for tap.  Concise and makes sense once explained (even intuitive to
> some).
>
> Have you ever tried to find usages of with in groovy with code examples
> with google without eventually loosing your temper ?
>
> For one thing, I think tap will be easier to google for.
>
> Marc Paquette
>
> Le 8 nov. 2016 à 12:32, Suderman Keith <su...@anc.org> a écrit :
>
>
> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>
> what about an overloaded with:
>
>
> +1
>
> Or even something like:
>
> myObject.with { ... } // current behaviour
> myObject.with(return:this) { ... } // returns this when finished.
> myObejct.with(return:new Object()) { ... } // returns a new Object when
> finished.
>
> This particular syntax would take a bit of extra parser arm waving since
> the `return` keyword is being used differently in this context.
>
> Keith
>
>
> myObject.with(true) {
>   // some code
> }
>
>
> or:
>
> myObject.with(returnThis:true) {
>   // some code
> }
>
>
> or... well I am sure there are many variants... just want to know if
> something like this doesn't cut it.
>
> bye Jochen
>
>
>
>

Re: .with() variant that returns the original object

[Marc Paquette <ma...@mac.com>]

+1 for tap.  Concise and makes sense once explained (even intuitive to some).

Have you ever tried to find usages of with in groovy with code examples with google without eventually loosing your temper ?  

For one thing, I think tap will be easier to google for.

Marc Paquette

> Le 8 nov. 2016 à 12:32, Suderman Keith <su...@anc.org> a écrit :
> 
> 
>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <bl...@gmx.org> wrote:
>> 
>> what about an overloaded with:
> 
> +1
> 
> Or even something like:
> 
> myObject.with { ... } // current behaviour
> myObject.with(return:this) { ... } // returns this when finished.
> myObejct.with(return:new Object()) { ... } // returns a new Object when finished.
> 
> This particular syntax would take a bit of extra parser arm waving since the `return` keyword is being used differently in this context.
> 
> Keith
> 
>> 
>>>> myObject.with(true) {
>>>>   // some code
>>>> }
>> 
>> or:
>> 
>>>> myObject.with(returnThis:true) {
>>>>   // some code
>>>> }
>> 
>> or... well I am sure there are many variants... just want to know if something like this doesn't cut it.
>> 
>> bye Jochen
> 

Re: .with() variant that returns the original object

[Suderman Keith <su...@anc.org>]

> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <bl...@gmx.org> wrote:
> 
> what about an overloaded with:

+1

Or even something like:

myObject.with { ... } // current behaviour
myObject.with(return:this) { ... } // returns this when finished.
myObejct.with(return:new Object()) { ... } // returns a new Object when finished.

This particular syntax would take a bit of extra parser arm waving since the `return` keyword is being used differently in this context.

Keith

> 
>>> myObject.with(true) {
>>>    // some code
>>> }
> 
> or:
> 
>>> myObject.with(returnThis:true) {
>>>    // some code
>>> }
> 
> or... well I am sure there are many variants... just want to know if something like this doesn't cut it.
> 
> bye Jochen

Re: .with() variant that returns the original object

[Jochen Theodorou <bl...@gmx.org>]

what about an overloaded with:

>> myObject.with(true) {
>>     // some code
>> }

or:

>> myObject.with(returnThis:true) {
>>     // some code
>> }

or... well I am sure there are many variants... just want to know if 
something like this doesn't cut it.

bye Jochen

Re: .with() variant that returns the original object

[Paul King <pa...@asert.com.au>]

I guess I should have listed my thoughts. I was initially thinking
apply to match Kotlin but the functional programming conflict is
likely to be an issue down the track, so I am thinking tap or
autoWith.


On Wed, Nov 9, 2016 at 12:44 AM, Cédric Champeau
<ce...@gmail.com> wrote:
> +1 to `tap`
>
> 2016-11-08 15:41 GMT+01:00 Guillaume Laforge <gl...@gmail.com>:
>>
>> I quite like "tap" (like in wiretaping, you're looking through the pipe)
>> We already have some rubyisms, so having one more is not a bad idea at all
>> for consistency.
>>
>> "doto" doesn't really help me understand what the method is about.
>>
>> "apply" is too overloaded, for functional programming, etc, so I'd really
>> avoid it.
>>
>> "tee" why not, but I didn't really knew what it was meanting.
>>
>> Not a big fan of auto, asThis, withThis or within.
>>
>> My preference clearly goes for tap!
>>
>> On Tue, Nov 8, 2016 at 3:34 PM, Paul King <pa...@asert.com.au> wrote:
>>>
>>> Hi everyone,
>>>
>>> We are hoping to release 2.5 not too far down the track. We are
>>> working on a revamped release process that is going to dramatically
>>> improve our ability to release early/release often but also comply
>>> with some additional Apache requirements that we follow these days.
>>> But more on that another time.
>>>
>>> One outstanding feature request targeted for potential inclusion in
>>> 2.5 is an alternative to .with{} that automatically returns the
>>> original object after executing the closure - recall that .with{}
>>> returns the last evaluated expression. The proposal is here:
>>>
>>> https://github.com/apache/groovy/pull/174/files
>>>
>>> We can't use the old name since that would break backward
>>> compatibility and is of utility in its current form in any case, so we
>>> are looking for a new name for the proposed method. If you look at the
>>> PR you will see it has been called 'tap' and 'doto' and numerous other
>>> names have been suggested. We regard naming as very important and
>>> normally we'd have very strong views about suitable names based on
>>> functionality and similar method names within the Groovy codebase. But
>>> in this instance, an obvious name hasn't popped out at us, so we are
>>> requesting feedback from the community about what names make most
>>> sense to you.
>>>
>>> Firstly, here is what the method does. I'll use 'tap' in these
>>> examples since that is what the PR currently uses but we can easily
>>> change that based on feedback.
>>>
>>> myObject.tap {
>>>     // some code
>>> }
>>>
>>> is equivalent to:
>>>
>>> myObject.with {
>>>     // some code
>>>     return this
>>> }
>>>
>>> Returning the 'self' object lends itself to various kinds of chaining,
>>> e.g.
>>>
>>> assert [:].tap {
>>>     a = 1
>>> }.tap {
>>>     b = 2
>>> } == [a:1, b:2]
>>>
>>> Or this one (adapted from a blog post[1] - and assuming you have a
>>> config.properties file containing answer=42 as one of the properties):
>>>
>>> assert new Properties().tap {
>>>     new FileInputStream('config.properties').withCloseable {
>>>         load(it)
>>>     }
>>> }.answer == '42'
>>>
>>> Here are some of the names that have been suggested with some commentary:
>>>
>>> doto    Used by Clojure. Not camel case as per normal convention
>>> (though we have upto and downto which also break that convention) and
>>> it isn't immediately obvious which is which between with and doto just
>>> from the names
>>>
>>> tap    Comes from Ruby and a previous Groovy extension outside core
>>> exists; meant to conjure up the idea of tapping into an object
>>>
>>> autoWith    Same as with but automatically returns self
>>>
>>> doWith   Again, hard to distinguish between doWith and with from the
>>> names themselves
>>>
>>> tee    An alternative name for tap
>>>
>>> auto    A shortened version of 'autoWith'
>>>
>>> apply    same as Kotlin which has copied Groovy's with but suffers
>>> from the downside that apply is already heavily overleaded in other
>>> contexts, e.g. functional programming
>>>
>>> withThis    Distinction with normal with a bit subtle perhaps
>>>
>>> asThis    Ditto
>>>
>>> within    Ditto
>>>
>>> I'll also point out the 'identity' is currently an alias for 'with',
>>> in case that provides any additional inspiration.
>>>
>>> Perhaps you dis/like one of the above or have some other suggestions.
>>> Let us know.
>>>
>>>
>>> Cheers, Paul.
>>>
>>>
>>> [1]
>>> http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/
>>
>>
>>
>>
>> --
>> Guillaume Laforge
>> Apache Groovy committer & PMC Vice-President
>> Developer Advocate @ Google Cloud Platform
>>
>> Blog: http://glaforge.appspot.com/
>> Social: @glaforge / Google+
>
>

Re: .with() variant that returns the original object

[Cédric Champeau <ce...@gmail.com>]

+1 to `tap`

2016-11-08 15:41 GMT+01:00 Guillaume Laforge <gl...@gmail.com>:

> I quite like "tap" (like in wiretaping, you're looking through the pipe)
> We already have some rubyisms, so having one more is not a bad idea at all
> for consistency.
>
> "doto" doesn't really help me understand what the method is about.
>
> "apply" is too overloaded, for functional programming, etc, so I'd really
> avoid it.
>
> "tee" why not, but I didn't really knew what it was meanting.
>
> Not a big fan of auto, asThis, withThis or within.
>
> My preference clearly goes for tap!
>
> On Tue, Nov 8, 2016 at 3:34 PM, Paul King <pa...@asert.com.au> wrote:
>
>> Hi everyone,
>>
>> We are hoping to release 2.5 not too far down the track. We are
>> working on a revamped release process that is going to dramatically
>> improve our ability to release early/release often but also comply
>> with some additional Apache requirements that we follow these days.
>> But more on that another time.
>>
>> One outstanding feature request targeted for potential inclusion in
>> 2.5 is an alternative to .with{} that automatically returns the
>> original object after executing the closure - recall that .with{}
>> returns the last evaluated expression. The proposal is here:
>>
>> https://github.com/apache/groovy/pull/174/files
>>
>> We can't use the old name since that would break backward
>> compatibility and is of utility in its current form in any case, so we
>> are looking for a new name for the proposed method. If you look at the
>> PR you will see it has been called 'tap' and 'doto' and numerous other
>> names have been suggested. We regard naming as very important and
>> normally we'd have very strong views about suitable names based on
>> functionality and similar method names within the Groovy codebase. But
>> in this instance, an obvious name hasn't popped out at us, so we are
>> requesting feedback from the community about what names make most
>> sense to you.
>>
>> Firstly, here is what the method does. I'll use 'tap' in these
>> examples since that is what the PR currently uses but we can easily
>> change that based on feedback.
>>
>> myObject.tap {
>>     // some code
>> }
>>
>> is equivalent to:
>>
>> myObject.with {
>>     // some code
>>     return this
>> }
>>
>> Returning the 'self' object lends itself to various kinds of chaining,
>> e.g.
>>
>> assert [:].tap {
>>     a = 1
>> }.tap {
>>     b = 2
>> } == [a:1, b:2]
>>
>> Or this one (adapted from a blog post[1] - and assuming you have a
>> config.properties file containing answer=42 as one of the properties):
>>
>> assert new Properties().tap {
>>     new FileInputStream('config.properties').withCloseable {
>>         load(it)
>>     }
>> }.answer == '42'
>>
>> Here are some of the names that have been suggested with some commentary:
>>
>> doto    Used by Clojure. Not camel case as per normal convention
>> (though we have upto and downto which also break that convention) and
>> it isn't immediately obvious which is which between with and doto just
>> from the names
>>
>> tap    Comes from Ruby and a previous Groovy extension outside core
>> exists; meant to conjure up the idea of tapping into an object
>>
>> autoWith    Same as with but automatically returns self
>>
>> doWith   Again, hard to distinguish between doWith and with from the
>> names themselves
>>
>> tee    An alternative name for tap
>>
>> auto    A shortened version of 'autoWith'
>>
>> apply    same as Kotlin which has copied Groovy's with but suffers
>> from the downside that apply is already heavily overleaded in other
>> contexts, e.g. functional programming
>>
>> withThis    Distinction with normal with a bit subtle perhaps
>>
>> asThis    Ditto
>>
>> within    Ditto
>>
>> I'll also point out the 'identity' is currently an alias for 'with',
>> in case that provides any additional inspiration.
>>
>> Perhaps you dis/like one of the above or have some other suggestions.
>> Let us know.
>>
>>
>> Cheers, Paul.
>>
>>
>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan
>> dard-library/
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Re: .with() variant that returns the original object

[Guillaume Laforge <gl...@gmail.com>]

I quite like "tap" (like in wiretaping, you're looking through the pipe)
We already have some rubyisms, so having one more is not a bad idea at all
for consistency.

"doto" doesn't really help me understand what the method is about.

"apply" is too overloaded, for functional programming, etc, so I'd really
avoid it.

"tee" why not, but I didn't really knew what it was meanting.

Not a big fan of auto, asThis, withThis or within.

My preference clearly goes for tap!

On Tue, Nov 8, 2016 at 3:34 PM, Paul King <pa...@asert.com.au> wrote:

> Hi everyone,
>
> We are hoping to release 2.5 not too far down the track. We are
> working on a revamped release process that is going to dramatically
> improve our ability to release early/release often but also comply
> with some additional Apache requirements that we follow these days.
> But more on that another time.
>
> One outstanding feature request targeted for potential inclusion in
> 2.5 is an alternative to .with{} that automatically returns the
> original object after executing the closure - recall that .with{}
> returns the last evaluated expression. The proposal is here:
>
> https://github.com/apache/groovy/pull/174/files
>
> We can't use the old name since that would break backward
> compatibility and is of utility in its current form in any case, so we
> are looking for a new name for the proposed method. If you look at the
> PR you will see it has been called 'tap' and 'doto' and numerous other
> names have been suggested. We regard naming as very important and
> normally we'd have very strong views about suitable names based on
> functionality and similar method names within the Groovy codebase. But
> in this instance, an obvious name hasn't popped out at us, so we are
> requesting feedback from the community about what names make most
> sense to you.
>
> Firstly, here is what the method does. I'll use 'tap' in these
> examples since that is what the PR currently uses but we can easily
> change that based on feedback.
>
> myObject.tap {
>     // some code
> }
>
> is equivalent to:
>
> myObject.with {
>     // some code
>     return this
> }
>
> Returning the 'self' object lends itself to various kinds of chaining, e.g.
>
> assert [:].tap {
>     a = 1
> }.tap {
>     b = 2
> } == [a:1, b:2]
>
> Or this one (adapted from a blog post[1] - and assuming you have a
> config.properties file containing answer=42 as one of the properties):
>
> assert new Properties().tap {
>     new FileInputStream('config.properties').withCloseable {
>         load(it)
>     }
> }.answer == '42'
>
> Here are some of the names that have been suggested with some commentary:
>
> doto    Used by Clojure. Not camel case as per normal convention
> (though we have upto and downto which also break that convention) and
> it isn't immediately obvious which is which between with and doto just
> from the names
>
> tap    Comes from Ruby and a previous Groovy extension outside core
> exists; meant to conjure up the idea of tapping into an object
>
> autoWith    Same as with but automatically returns self
>
> doWith   Again, hard to distinguish between doWith and with from the
> names themselves
>
> tee    An alternative name for tap
>
> auto    A shortened version of 'autoWith'
>
> apply    same as Kotlin which has copied Groovy's with but suffers
> from the downside that apply is already heavily overleaded in other
> contexts, e.g. functional programming
>
> withThis    Distinction with normal with a bit subtle perhaps
>
> asThis    Ditto
>
> within    Ditto
>
> I'll also point out the 'identity' is currently an alias for 'with',
> in case that provides any additional inspiration.
>
> Perhaps you dis/like one of the above or have some other suggestions.
> Let us know.
>
>
> Cheers, Paul.
>
>
> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-
> standard-library/
>



-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>

Re: .with() variant that returns the original object

[James Kleeh <ja...@gmail.com>]

I vote for withThis for similar reasons as Keith

> On Nov 8, 2016, at 10:57 AM, Suderman Keith <su...@anc.org> wrote:
> 
> +1 for withThis
> 
> withThis{} indicates it is just another form of the .with{} method that returns this, that seems the most logical and consistent name.  The name `tap` strikes me as non-sensical; what does doing something "with" an object have to do with tapping a beer keg or wire tapping a phone line?
> 
> My two cents.
> Keith
> 
>> On Nov 8, 2016, at 10:20 AM, Winnebeck, Jason <Ja...@windstream.com> wrote:
>> 
>> Normally, I'd say that we should use Java as first inspiration and all other popular JVM languages (including Kotlin) as second inspiration, because it's really nice as a JVM-ecosystem developer to have a common set of terminology and methods. However, I agree with Paul's analysis. The meaning of "apply" conflicts with Java's Function.apply as well as apply from JavaScript world (I don't know if others agree but I think of Groovy in a similar mindset to JS). The closest Java signature is Function.identity, but identity is already used in Groovy and most think of identity function as "doing nothing".
>> 
>> Therefore, my vote is for tap. When I see tap it makes sense to me. It makes me think of the Unix "tee" shell command that does the same thing by sending the object to another command and returning the same output unmodified. The usage of tap here is also consistent with network terminology (a network tap), and real-world usage (such as "tapping" a water pipe). A tap observes the input without changing it and allowing it to pass unimpeded, unlike a filter or a function.
>> 
>> Jason
>> 
>> -----Original Message-----
>> From: Paul King [mailto:paulk@asert.com.au] 
>> Sent: Tuesday, November 08, 2016 9:34 AM
>> To: users@groovy.apache.org
>> Subject: .with() variant that returns the original object
>> 
>> Hi everyone,
>> 
>> We are hoping to release 2.5 not too far down the track. We are working on a revamped release process that is going to dramatically improve our ability to release early/release often but also comply with some additional Apache requirements that we follow these days.
>> But more on that another time.
>> 
>> One outstanding feature request targeted for potential inclusion in
>> 2.5 is an alternative to .with{} that automatically returns the original object after executing the closure - recall that .with{} returns the last evaluated expression. The proposal is here:
>> 
>> https://github.com/apache/groovy/pull/174/files
>> 
>> We can't use the old name since that would break backward compatibility and is of utility in its current form in any case, so we are looking for a new name for the proposed method. If you look at the PR you will see it has been called 'tap' and 'doto' and numerous other names have been suggested. We regard naming as very important and normally we'd have very strong views about suitable names based on functionality and similar method names within the Groovy codebase. But in this instance, an obvious name hasn't popped out at us, so we are requesting feedback from the community about what names make most sense to you.
>> 
>> Firstly, here is what the method does. I'll use 'tap' in these examples since that is what the PR currently uses but we can easily change that based on feedback.
>> 
>> myObject.tap {
>>   // some code
>> }
>> 
>> is equivalent to:
>> 
>> myObject.with {
>>   // some code
>>   return this
>> }
>> 
>> Returning the 'self' object lends itself to various kinds of chaining, e.g.
>> 
>> assert [:].tap {
>>   a = 1
>> }.tap {
>>   b = 2
>> } == [a:1, b:2]
>> 
>> Or this one (adapted from a blog post[1] - and assuming you have a config.properties file containing answer=42 as one of the properties):
>> 
>> assert new Properties().tap {
>>   new FileInputStream('config.properties').withCloseable {
>>       load(it)
>>   }
>> }.answer == '42'
>> 
>> Here are some of the names that have been suggested with some commentary:
>> 
>> doto    Used by Clojure. Not camel case as per normal convention
>> (though we have upto and downto which also break that convention) and it isn't immediately obvious which is which between with and doto just from the names
>> 
>> tap    Comes from Ruby and a previous Groovy extension outside core
>> exists; meant to conjure up the idea of tapping into an object
>> 
>> autoWith    Same as with but automatically returns self
>> 
>> doWith   Again, hard to distinguish between doWith and with from the
>> names themselves
>> 
>> tee    An alternative name for tap
>> 
>> auto    A shortened version of 'autoWith'
>> 
>> apply    same as Kotlin which has copied Groovy's with but suffers
>> from the downside that apply is already heavily overleaded in other contexts, e.g. functional programming
>> 
>> withThis    Distinction with normal with a bit subtle perhaps
>> 
>> asThis    Ditto
>> 
>> within    Ditto
>> 
>> I'll also point out the 'identity' is currently an alias for 'with', in case that provides any additional inspiration.
>> 
>> Perhaps you dis/like one of the above or have some other suggestions.
>> Let us know.
>> 
>> 
>> Cheers, Paul.
>> 
>> 
>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/
>> 
>> This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.
> 

Re: .with() variant that returns the original object

[Suderman Keith <su...@anc.org>]

+1 for withThis

withThis{} indicates it is just another form of the .with{} method that returns this, that seems the most logical and consistent name.  The name `tap` strikes me as non-sensical; what does doing something "with" an object have to do with tapping a beer keg or wire tapping a phone line?

My two cents.
Keith

> On Nov 8, 2016, at 10:20 AM, Winnebeck, Jason <Ja...@windstream.com> wrote:
> 
> Normally, I'd say that we should use Java as first inspiration and all other popular JVM languages (including Kotlin) as second inspiration, because it's really nice as a JVM-ecosystem developer to have a common set of terminology and methods. However, I agree with Paul's analysis. The meaning of "apply" conflicts with Java's Function.apply as well as apply from JavaScript world (I don't know if others agree but I think of Groovy in a similar mindset to JS). The closest Java signature is Function.identity, but identity is already used in Groovy and most think of identity function as "doing nothing".
> 
> Therefore, my vote is for tap. When I see tap it makes sense to me. It makes me think of the Unix "tee" shell command that does the same thing by sending the object to another command and returning the same output unmodified. The usage of tap here is also consistent with network terminology (a network tap), and real-world usage (such as "tapping" a water pipe). A tap observes the input without changing it and allowing it to pass unimpeded, unlike a filter or a function.
> 
> Jason
> 
> -----Original Message-----
> From: Paul King [mailto:paulk@asert.com.au] 
> Sent: Tuesday, November 08, 2016 9:34 AM
> To: users@groovy.apache.org
> Subject: .with() variant that returns the original object
> 
> Hi everyone,
> 
> We are hoping to release 2.5 not too far down the track. We are working on a revamped release process that is going to dramatically improve our ability to release early/release often but also comply with some additional Apache requirements that we follow these days.
> But more on that another time.
> 
> One outstanding feature request targeted for potential inclusion in
> 2.5 is an alternative to .with{} that automatically returns the original object after executing the closure - recall that .with{} returns the last evaluated expression. The proposal is here:
> 
> https://github.com/apache/groovy/pull/174/files
> 
> We can't use the old name since that would break backward compatibility and is of utility in its current form in any case, so we are looking for a new name for the proposed method. If you look at the PR you will see it has been called 'tap' and 'doto' and numerous other names have been suggested. We regard naming as very important and normally we'd have very strong views about suitable names based on functionality and similar method names within the Groovy codebase. But in this instance, an obvious name hasn't popped out at us, so we are requesting feedback from the community about what names make most sense to you.
> 
> Firstly, here is what the method does. I'll use 'tap' in these examples since that is what the PR currently uses but we can easily change that based on feedback.
> 
> myObject.tap {
>    // some code
> }
> 
> is equivalent to:
> 
> myObject.with {
>    // some code
>    return this
> }
> 
> Returning the 'self' object lends itself to various kinds of chaining, e.g.
> 
> assert [:].tap {
>    a = 1
> }.tap {
>    b = 2
> } == [a:1, b:2]
> 
> Or this one (adapted from a blog post[1] - and assuming you have a config.properties file containing answer=42 as one of the properties):
> 
> assert new Properties().tap {
>    new FileInputStream('config.properties').withCloseable {
>        load(it)
>    }
> }.answer == '42'
> 
> Here are some of the names that have been suggested with some commentary:
> 
> doto    Used by Clojure. Not camel case as per normal convention
> (though we have upto and downto which also break that convention) and it isn't immediately obvious which is which between with and doto just from the names
> 
> tap    Comes from Ruby and a previous Groovy extension outside core
> exists; meant to conjure up the idea of tapping into an object
> 
> autoWith    Same as with but automatically returns self
> 
> doWith   Again, hard to distinguish between doWith and with from the
> names themselves
> 
> tee    An alternative name for tap
> 
> auto    A shortened version of 'autoWith'
> 
> apply    same as Kotlin which has copied Groovy's with but suffers
> from the downside that apply is already heavily overleaded in other contexts, e.g. functional programming
> 
> withThis    Distinction with normal with a bit subtle perhaps
> 
> asThis    Ditto
> 
> within    Ditto
> 
> I'll also point out the 'identity' is currently an alias for 'with', in case that provides any additional inspiration.
> 
> Perhaps you dis/like one of the above or have some other suggestions.
> Let us know.
> 
> 
> Cheers, Paul.
> 
> 
> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/
> 
> This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

RE: .with() variant that returns the original object

["Winnebeck, Jason" <Ja...@windstream.com>]

Normally, I'd say that we should use Java as first inspiration and all other popular JVM languages (including Kotlin) as second inspiration, because it's really nice as a JVM-ecosystem developer to have a common set of terminology and methods. However, I agree with Paul's analysis. The meaning of "apply" conflicts with Java's Function.apply as well as apply from JavaScript world (I don't know if others agree but I think of Groovy in a similar mindset to JS). The closest Java signature is Function.identity, but identity is already used in Groovy and most think of identity function as "doing nothing".

Therefore, my vote is for tap. When I see tap it makes sense to me. It makes me think of the Unix "tee" shell command that does the same thing by sending the object to another command and returning the same output unmodified. The usage of tap here is also consistent with network terminology (a network tap), and real-world usage (such as "tapping" a water pipe). A tap observes the input without changing it and allowing it to pass unimpeded, unlike a filter or a function.

Jason

-----Original Message-----
From: Paul King [mailto:paulk@asert.com.au] 
Sent: Tuesday, November 08, 2016 9:34 AM
To: users@groovy.apache.org
Subject: .with() variant that returns the original object

Hi everyone,

We are hoping to release 2.5 not too far down the track. We are working on a revamped release process that is going to dramatically improve our ability to release early/release often but also comply with some additional Apache requirements that we follow these days.
But more on that another time.

One outstanding feature request targeted for potential inclusion in
2.5 is an alternative to .with{} that automatically returns the original object after executing the closure - recall that .with{} returns the last evaluated expression. The proposal is here:

https://github.com/apache/groovy/pull/174/files

We can't use the old name since that would break backward compatibility and is of utility in its current form in any case, so we are looking for a new name for the proposed method. If you look at the PR you will see it has been called 'tap' and 'doto' and numerous other names have been suggested. We regard naming as very important and normally we'd have very strong views about suitable names based on functionality and similar method names within the Groovy codebase. But in this instance, an obvious name hasn't popped out at us, so we are requesting feedback from the community about what names make most sense to you.

Firstly, here is what the method does. I'll use 'tap' in these examples since that is what the PR currently uses but we can easily change that based on feedback.

myObject.tap {
    // some code
}

is equivalent to:

myObject.with {
    // some code
    return this
}

Returning the 'self' object lends itself to various kinds of chaining, e.g.

assert [:].tap {
    a = 1
}.tap {
    b = 2
} == [a:1, b:2]

Or this one (adapted from a blog post[1] - and assuming you have a config.properties file containing answer=42 as one of the properties):

assert new Properties().tap {
    new FileInputStream('config.properties').withCloseable {
        load(it)
    }
}.answer == '42'

Here are some of the names that have been suggested with some commentary:

doto    Used by Clojure. Not camel case as per normal convention
(though we have upto and downto which also break that convention) and it isn't immediately obvious which is which between with and doto just from the names

tap    Comes from Ruby and a previous Groovy extension outside core
exists; meant to conjure up the idea of tapping into an object

autoWith    Same as with but automatically returns self

doWith   Again, hard to distinguish between doWith and with from the
names themselves

tee    An alternative name for tap

auto    A shortened version of 'autoWith'

apply    same as Kotlin which has copied Groovy's with but suffers
from the downside that apply is already heavily overleaded in other contexts, e.g. functional programming

withThis    Distinction with normal with a bit subtle perhaps

asThis    Ditto

within    Ditto

I'll also point out the 'identity' is currently an alias for 'with', in case that provides any additional inspiration.

Perhaps you dis/like one of the above or have some other suggestions.
Let us know.


Cheers, Paul.


[1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/

This email message and any attachments are for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message and any attachments.

Re: .with() variant that returns the original object

[Krzysztof Kowalczyk <ko...@gmail.com>]

Yes, that's a problem but "tap" means nothing to me so I need to consult
docs to understand code with "tap".

On 8 November 2016 at 15:09, Guillaume Laforge <gl...@gmail.com> wrote:

> "having" makes me think too much of SQL, so it might be a bit misleading?
>
> On Tue, Nov 8, 2016 at 4:01 PM, Krzysztof Kowalczyk <
> kowalczyk.krzysztof@gmail.com> wrote:
>
>> Hi,
>>
>> What about "having":
>>
>> house.having {
>>   windows.open()
>> }.having{
>>   doors.locked()
>> }
>>
>> car.having { wheels.having{ screws.allInPlace = true }}
>>
>> I guess withThis could be an alias (maybe even deprecated) so people
>> would be able to find other method when they notice that returning this is
>> silly.
>>
>> Regards,
>> Krzysztof
>>
>> On 8 November 2016 at 14:53, Kostas Saidis <sa...@gmail.com> wrote:
>>
>>> +1 for tap.
>>>
>>> Alternatives don't seem to fit well.
>>>
>>> My proposal is touch.
>>>
>>> Example:
>>>
>>> assert [:].touch {
>>>     a = 1
>>> }.touch {
>>>     b = 2
>>> } == [a:1, b:2]
>>>
>>> If you start touching the object, it is rather intuitive that you get
>>> the object itself as a result :)
>>>
>>> Cheers,
>>> Kostas
>>>
>>> PS: Some guys here may also like avec, perhaps?
>>>
>>>
>>>
>>> On 8/11/2016 4:34 μμ, Paul King wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> We are hoping to release 2.5 not too far down the track. We are
>>>> working on a revamped release process that is going to dramatically
>>>> improve our ability to release early/release often but also comply
>>>> with some additional Apache requirements that we follow these days.
>>>> But more on that another time.
>>>>
>>>> One outstanding feature request targeted for potential inclusion in
>>>> 2.5 is an alternative to .with{} that automatically returns the
>>>> original object after executing the closure - recall that .with{}
>>>> returns the last evaluated expression. The proposal is here:
>>>>
>>>> https://github.com/apache/groovy/pull/174/files
>>>>
>>>> We can't use the old name since that would break backward
>>>> compatibility and is of utility in its current form in any case, so we
>>>> are looking for a new name for the proposed method. If you look at the
>>>> PR you will see it has been called 'tap' and 'doto' and numerous other
>>>> names have been suggested. We regard naming as very important and
>>>> normally we'd have very strong views about suitable names based on
>>>> functionality and similar method names within the Groovy codebase. But
>>>> in this instance, an obvious name hasn't popped out at us, so we are
>>>> requesting feedback from the community about what names make most
>>>> sense to you.
>>>>
>>>> Firstly, here is what the method does. I'll use 'tap' in these
>>>> examples since that is what the PR currently uses but we can easily
>>>> change that based on feedback.
>>>>
>>>> myObject.tap {
>>>>      // some code
>>>> }
>>>>
>>>> is equivalent to:
>>>>
>>>> myObject.with {
>>>>      // some code
>>>>      return this
>>>> }
>>>>
>>>> Returning the 'self' object lends itself to various kinds of chaining,
>>>> e.g.
>>>>
>>>> assert [:].tap {
>>>>      a = 1
>>>> }.tap {
>>>>      b = 2
>>>> } == [a:1, b:2]
>>>>
>>>> Or this one (adapted from a blog post[1] - and assuming you have a
>>>> config.properties file containing answer=42 as one of the properties):
>>>>
>>>> assert new Properties().tap {
>>>>      new FileInputStream('config.properties').withCloseable {
>>>>          load(it)
>>>>      }
>>>> }.answer == '42'
>>>>
>>>> Here are some of the names that have been suggested with some
>>>> commentary:
>>>>
>>>> doto    Used by Clojure. Not camel case as per normal convention
>>>> (though we have upto and downto which also break that convention) and
>>>> it isn't immediately obvious which is which between with and doto just
>>>> from the names
>>>>
>>>> tap    Comes from Ruby and a previous Groovy extension outside core
>>>> exists; meant to conjure up the idea of tapping into an object
>>>>
>>>> autoWith    Same as with but automatically returns self
>>>>
>>>> doWith   Again, hard to distinguish between doWith and with from the
>>>> names themselves
>>>>
>>>> tee    An alternative name for tap
>>>>
>>>> auto    A shortened version of 'autoWith'
>>>>
>>>> apply    same as Kotlin which has copied Groovy's with but suffers
>>>> from the downside that apply is already heavily overleaded in other
>>>> contexts, e.g. functional programming
>>>>
>>>> withThis    Distinction with normal with a bit subtle perhaps
>>>>
>>>> asThis    Ditto
>>>>
>>>> within    Ditto
>>>>
>>>> I'll also point out the 'identity' is currently an alias for 'with',
>>>> in case that provides any additional inspiration.
>>>>
>>>> Perhaps you dis/like one of the above or have some other suggestions.
>>>> Let us know.
>>>>
>>>>
>>>> Cheers, Paul.
>>>>
>>>>
>>>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan
>>>> dard-library/
>>>>
>>>>
>>>
>>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Re: .with() variant that returns the original object

[Guillaume Laforge <gl...@gmail.com>]

"having" makes me think too much of SQL, so it might be a bit misleading?

On Tue, Nov 8, 2016 at 4:01 PM, Krzysztof Kowalczyk <
kowalczyk.krzysztof@gmail.com> wrote:

> Hi,
>
> What about "having":
>
> house.having {
>   windows.open()
> }.having{
>   doors.locked()
> }
>
> car.having { wheels.having{ screws.allInPlace = true }}
>
> I guess withThis could be an alias (maybe even deprecated) so people would
> be able to find other method when they notice that returning this is silly.
>
> Regards,
> Krzysztof
>
> On 8 November 2016 at 14:53, Kostas Saidis <sa...@gmail.com> wrote:
>
>> +1 for tap.
>>
>> Alternatives don't seem to fit well.
>>
>> My proposal is touch.
>>
>> Example:
>>
>> assert [:].touch {
>>     a = 1
>> }.touch {
>>     b = 2
>> } == [a:1, b:2]
>>
>> If you start touching the object, it is rather intuitive that you get the
>> object itself as a result :)
>>
>> Cheers,
>> Kostas
>>
>> PS: Some guys here may also like avec, perhaps?
>>
>>
>>
>> On 8/11/2016 4:34 μμ, Paul King wrote:
>>
>>> Hi everyone,
>>>
>>> We are hoping to release 2.5 not too far down the track. We are
>>> working on a revamped release process that is going to dramatically
>>> improve our ability to release early/release often but also comply
>>> with some additional Apache requirements that we follow these days.
>>> But more on that another time.
>>>
>>> One outstanding feature request targeted for potential inclusion in
>>> 2.5 is an alternative to .with{} that automatically returns the
>>> original object after executing the closure - recall that .with{}
>>> returns the last evaluated expression. The proposal is here:
>>>
>>> https://github.com/apache/groovy/pull/174/files
>>>
>>> We can't use the old name since that would break backward
>>> compatibility and is of utility in its current form in any case, so we
>>> are looking for a new name for the proposed method. If you look at the
>>> PR you will see it has been called 'tap' and 'doto' and numerous other
>>> names have been suggested. We regard naming as very important and
>>> normally we'd have very strong views about suitable names based on
>>> functionality and similar method names within the Groovy codebase. But
>>> in this instance, an obvious name hasn't popped out at us, so we are
>>> requesting feedback from the community about what names make most
>>> sense to you.
>>>
>>> Firstly, here is what the method does. I'll use 'tap' in these
>>> examples since that is what the PR currently uses but we can easily
>>> change that based on feedback.
>>>
>>> myObject.tap {
>>>      // some code
>>> }
>>>
>>> is equivalent to:
>>>
>>> myObject.with {
>>>      // some code
>>>      return this
>>> }
>>>
>>> Returning the 'self' object lends itself to various kinds of chaining,
>>> e.g.
>>>
>>> assert [:].tap {
>>>      a = 1
>>> }.tap {
>>>      b = 2
>>> } == [a:1, b:2]
>>>
>>> Or this one (adapted from a blog post[1] - and assuming you have a
>>> config.properties file containing answer=42 as one of the properties):
>>>
>>> assert new Properties().tap {
>>>      new FileInputStream('config.properties').withCloseable {
>>>          load(it)
>>>      }
>>> }.answer == '42'
>>>
>>> Here are some of the names that have been suggested with some commentary:
>>>
>>> doto    Used by Clojure. Not camel case as per normal convention
>>> (though we have upto and downto which also break that convention) and
>>> it isn't immediately obvious which is which between with and doto just
>>> from the names
>>>
>>> tap    Comes from Ruby and a previous Groovy extension outside core
>>> exists; meant to conjure up the idea of tapping into an object
>>>
>>> autoWith    Same as with but automatically returns self
>>>
>>> doWith   Again, hard to distinguish between doWith and with from the
>>> names themselves
>>>
>>> tee    An alternative name for tap
>>>
>>> auto    A shortened version of 'autoWith'
>>>
>>> apply    same as Kotlin which has copied Groovy's with but suffers
>>> from the downside that apply is already heavily overleaded in other
>>> contexts, e.g. functional programming
>>>
>>> withThis    Distinction with normal with a bit subtle perhaps
>>>
>>> asThis    Ditto
>>>
>>> within    Ditto
>>>
>>> I'll also point out the 'identity' is currently an alias for 'with',
>>> in case that provides any additional inspiration.
>>>
>>> Perhaps you dis/like one of the above or have some other suggestions.
>>> Let us know.
>>>
>>>
>>> Cheers, Paul.
>>>
>>>
>>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan
>>> dard-library/
>>>
>>>
>>
>


-- 
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Blog: http://glaforge.appspot.com/
Social: @glaforge <http://twitter.com/glaforge> / Google+
<https://plus.google.com/u/0/114130972232398734985/posts>

Re: .with() variant that returns the original object

[Krzysztof Kowalczyk <ko...@gmail.com>]

Hi,

What about "having":

house.having {
  windows.open()
}.having{
  doors.locked()
}

car.having { wheels.having{ screws.allInPlace = true }}

I guess withThis could be an alias (maybe even deprecated) so people would
be able to find other method when they notice that returning this is silly.

Regards,
Krzysztof

On 8 November 2016 at 14:53, Kostas Saidis <sa...@gmail.com> wrote:

> +1 for tap.
>
> Alternatives don't seem to fit well.
>
> My proposal is touch.
>
> Example:
>
> assert [:].touch {
>     a = 1
> }.touch {
>     b = 2
> } == [a:1, b:2]
>
> If you start touching the object, it is rather intuitive that you get the
> object itself as a result :)
>
> Cheers,
> Kostas
>
> PS: Some guys here may also like avec, perhaps?
>
>
>
> On 8/11/2016 4:34 μμ, Paul King wrote:
>
>> Hi everyone,
>>
>> We are hoping to release 2.5 not too far down the track. We are
>> working on a revamped release process that is going to dramatically
>> improve our ability to release early/release often but also comply
>> with some additional Apache requirements that we follow these days.
>> But more on that another time.
>>
>> One outstanding feature request targeted for potential inclusion in
>> 2.5 is an alternative to .with{} that automatically returns the
>> original object after executing the closure - recall that .with{}
>> returns the last evaluated expression. The proposal is here:
>>
>> https://github.com/apache/groovy/pull/174/files
>>
>> We can't use the old name since that would break backward
>> compatibility and is of utility in its current form in any case, so we
>> are looking for a new name for the proposed method. If you look at the
>> PR you will see it has been called 'tap' and 'doto' and numerous other
>> names have been suggested. We regard naming as very important and
>> normally we'd have very strong views about suitable names based on
>> functionality and similar method names within the Groovy codebase. But
>> in this instance, an obvious name hasn't popped out at us, so we are
>> requesting feedback from the community about what names make most
>> sense to you.
>>
>> Firstly, here is what the method does. I'll use 'tap' in these
>> examples since that is what the PR currently uses but we can easily
>> change that based on feedback.
>>
>> myObject.tap {
>>      // some code
>> }
>>
>> is equivalent to:
>>
>> myObject.with {
>>      // some code
>>      return this
>> }
>>
>> Returning the 'self' object lends itself to various kinds of chaining,
>> e.g.
>>
>> assert [:].tap {
>>      a = 1
>> }.tap {
>>      b = 2
>> } == [a:1, b:2]
>>
>> Or this one (adapted from a blog post[1] - and assuming you have a
>> config.properties file containing answer=42 as one of the properties):
>>
>> assert new Properties().tap {
>>      new FileInputStream('config.properties').withCloseable {
>>          load(it)
>>      }
>> }.answer == '42'
>>
>> Here are some of the names that have been suggested with some commentary:
>>
>> doto    Used by Clojure. Not camel case as per normal convention
>> (though we have upto and downto which also break that convention) and
>> it isn't immediately obvious which is which between with and doto just
>> from the names
>>
>> tap    Comes from Ruby and a previous Groovy extension outside core
>> exists; meant to conjure up the idea of tapping into an object
>>
>> autoWith    Same as with but automatically returns self
>>
>> doWith   Again, hard to distinguish between doWith and with from the
>> names themselves
>>
>> tee    An alternative name for tap
>>
>> auto    A shortened version of 'autoWith'
>>
>> apply    same as Kotlin which has copied Groovy's with but suffers
>> from the downside that apply is already heavily overleaded in other
>> contexts, e.g. functional programming
>>
>> withThis    Distinction with normal with a bit subtle perhaps
>>
>> asThis    Ditto
>>
>> within    Ditto
>>
>> I'll also point out the 'identity' is currently an alias for 'with',
>> in case that provides any additional inspiration.
>>
>> Perhaps you dis/like one of the above or have some other suggestions.
>> Let us know.
>>
>>
>> Cheers, Paul.
>>
>>
>> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-stan
>> dard-library/
>>
>>
>

Re: .with() variant that returns the original object

[Kostas Saidis <sa...@gmail.com>]

+1 for tap.

Alternatives don't seem to fit well.

My proposal is touch.

Example:

assert [:].touch {
     a = 1
}.touch {
     b = 2
} == [a:1, b:2]

If you start touching the object, it is rather intuitive that you get 
the object itself as a result :)

Cheers,
Kostas

PS: Some guys here may also like avec, perhaps?


On 8/11/2016 4:34 \u03bc\u03bc, Paul King wrote:
> Hi everyone,
>
> We are hoping to release 2.5 not too far down the track. We are
> working on a revamped release process that is going to dramatically
> improve our ability to release early/release often but also comply
> with some additional Apache requirements that we follow these days.
> But more on that another time.
>
> One outstanding feature request targeted for potential inclusion in
> 2.5 is an alternative to .with{} that automatically returns the
> original object after executing the closure - recall that .with{}
> returns the last evaluated expression. The proposal is here:
>
> https://github.com/apache/groovy/pull/174/files
>
> We can't use the old name since that would break backward
> compatibility and is of utility in its current form in any case, so we
> are looking for a new name for the proposed method. If you look at the
> PR you will see it has been called 'tap' and 'doto' and numerous other
> names have been suggested. We regard naming as very important and
> normally we'd have very strong views about suitable names based on
> functionality and similar method names within the Groovy codebase. But
> in this instance, an obvious name hasn't popped out at us, so we are
> requesting feedback from the community about what names make most
> sense to you.
>
> Firstly, here is what the method does. I'll use 'tap' in these
> examples since that is what the PR currently uses but we can easily
> change that based on feedback.
>
> myObject.tap {
>      // some code
> }
>
> is equivalent to:
>
> myObject.with {
>      // some code
>      return this
> }
>
> Returning the 'self' object lends itself to various kinds of chaining, e.g.
>
> assert [:].tap {
>      a = 1
> }.tap {
>      b = 2
> } == [a:1, b:2]
>
> Or this one (adapted from a blog post[1] - and assuming you have a
> config.properties file containing answer=42 as one of the properties):
>
> assert new Properties().tap {
>      new FileInputStream('config.properties').withCloseable {
>          load(it)
>      }
> }.answer == '42'
>
> Here are some of the names that have been suggested with some commentary:
>
> doto    Used by Clojure. Not camel case as per normal convention
> (though we have upto and downto which also break that convention) and
> it isn't immediately obvious which is which between with and doto just
> from the names
>
> tap    Comes from Ruby and a previous Groovy extension outside core
> exists; meant to conjure up the idea of tapping into an object
>
> autoWith    Same as with but automatically returns self
>
> doWith   Again, hard to distinguish between doWith and with from the
> names themselves
>
> tee    An alternative name for tap
>
> auto    A shortened version of 'autoWith'
>
> apply    same as Kotlin which has copied Groovy's with but suffers
> from the downside that apply is already heavily overleaded in other
> contexts, e.g. functional programming
>
> withThis    Distinction with normal with a bit subtle perhaps
>
> asThis    Ditto
>
> within    Ditto
>
> I'll also point out the 'identity' is currently an alias for 'with',
> in case that provides any additional inspiration.
>
> Perhaps you dis/like one of the above or have some other suggestions.
> Let us know.
>
>
> Cheers, Paul.
>
>
> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/
>