What about a syntax for closures that return 'this' implicitly? On Wed, Nov 9, 2016 at 2:57 AM, [email protected] <[email protected]> wrote:
> Paul, > > > On 9. 11. 2016, at 2:43 AM, Paul King <[email protected]> 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 > > <[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 > > -- Linux. The choice of a GNU generation.
