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>
:
> 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]
> Sent: Tuesday, November 08, 2016 7:53 PM
> To: users@groovy.apache.org; 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> 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>
> 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
> >>
> >>
> >> On Tue, Nov 8, 2016 at 12:43 PM, Marc Paquette <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> a écrit :
> >>>
> >>>
> >>> On Nov 8, 2016, at 11:41 AM, Jochen Theodorou <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.
>
