groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Winnebeck, Jason" <Jason.Winneb...@windstream.com>
Subject RE: .with() variant that returns the original object
Date Wed, 09 Nov 2016 14:07:50 GMT
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 <Jason.Winnebeck@windstream.com<mailto:Jason.Winnebeck@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<mailto:pjmitchell@blueyonder.co.uk>]
Sent: Tuesday, November 08, 2016 7:53 PM
To: users@groovy.apache.org<mailto:users@groovy.apache.org>; paulk@asert.com.au<mailto: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 <paulk@asert.com.au<mailto:paulk@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 <henrik@netgate.net<mailto:henrik@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<mailto:jerrywiltse@gmail.com>
>>
>>
>> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <marcpa@mac.com<mailto:marcpa@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<mailto:suderman@anc.org>>
a écrit :
>>>
>>>
>>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <blackdrag@gmx.org<mailto:blackdrag@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.

Mime
View raw message