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.champ...@gmail.com]
Sent: Wednesday, November 09, 2016 9:03 AM
To: users@groovy.apache.org
Cc: pa...@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
<jason.winneb...@windstream.com<mailto:jason.winneb...@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:pjmitch...@blueyonder.co.uk<mailto:pjmitch...@blueyonder.co.uk>]
Sent: Tuesday, November 08, 2016 7:53 PM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>;
pa...@asert.com.au<mailto:pa...@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<mailto: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
> <hen...@netgate.net<mailto:hen...@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
>> jerrywil...@gmail.com<mailto:jerrywil...@gmail.com>
>>
>>
>> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette
>> <mar...@mac.com<mailto:mar...@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
>>> <suder...@anc.org<mailto:suder...@anc.org>> a écrit :
>>>
>>>
>>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou
>>> <blackd...@gmx.org<mailto:blackd...@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.
