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 <[email protected]> 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
