groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <pa...@asert.com.au>
Subject Re: .with() variant that returns the original object
Date Wed, 09 Nov 2016 01:43:14 GMT
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
<pjmitchell@blueyonder.co.uk> 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

Mime
View raw message