groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: .with() variant that returns the original object
Date Wed, 09 Nov 2016 01:57:22 GMT

> On 9. 11. 2016, at 2:43 AM, Paul King <> 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,

> 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
> <> 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
>> Just my 2-cents worth.
>> Phil Mitchell

View raw message