Hi there,
as always I can be wrong, but I do not think it is possible to find a good name
which (a) expresses the behaviour well (b) along with its very close similarity
to 'with', which is a problem of 'tap's etc can be found.
Therefore myself, I would advocate for
(a) **renaming current 'with'** (keeping, of course, the original name as an
equivalent for backward compatibility; just by convention discourage its use in
new code)
(b) and adding an appropriate variant of the name for the new functionality.
Myself, I would probably like
- 'doWith' for the new one -- considering returning 'this' a reasonable
default, which it is
- 'valueWith' as a modern equivalent of 'with' for the old functionality
or perhaps
- 'tap' for the new one (for all the reasons others expressed in favour of the
name)
- 'valueTapping' as a modern equivalent of 'with' for the old functionality
or something like that.
All the best,
OC
On 8. 11. 2016, at 15:34, Paul King <pa...@asert.com.au> wrote:
> Hi everyone,
>
> We are hoping to release 2.5 not too far down the track. We are
> working on a revamped release process that is going to dramatically
> improve our ability to release early/release often but also comply
> with some additional Apache requirements that we follow these days.
> But more on that another time.
>
> One outstanding feature request targeted for potential inclusion in
> 2.5 is an alternative to .with{} that automatically returns the
> original object after executing the closure - recall that .with{}
> returns the last evaluated expression. The proposal is here:
>
> https://github.com/apache/groovy/pull/174/files
>
> We can't use the old name since that would break backward
> compatibility and is of utility in its current form in any case, so we
> are looking for a new name for the proposed method. If you look at the
> PR you will see it has been called 'tap' and 'doto' and numerous other
> names have been suggested. We regard naming as very important and
> normally we'd have very strong views about suitable names based on
> functionality and similar method names within the Groovy codebase. But
> in this instance, an obvious name hasn't popped out at us, so we are
> requesting feedback from the community about what names make most
> sense to you.
>
> Firstly, here is what the method does. I'll use 'tap' in these
> examples since that is what the PR currently uses but we can easily
> change that based on feedback.
>
> myObject.tap {
> // some code
> }
>
> is equivalent to:
>
> myObject.with {
> // some code
> return this
> }
>
> Returning the 'self' object lends itself to various kinds of chaining, e.g.
>
> assert [:].tap {
> a = 1
> }.tap {
> b = 2
> } == [a:1, b:2]
>
> Or this one (adapted from a blog post[1] - and assuming you have a
> config.properties file containing answer=42 as one of the properties):
>
> assert new Properties().tap {
> new FileInputStream('config.properties').withCloseable {
> load(it)
> }
> }.answer == '42'
>
> Here are some of the names that have been suggested with some commentary:
>
> doto Used by Clojure. Not camel case as per normal convention
> (though we have upto and downto which also break that convention) and
> it isn't immediately obvious which is which between with and doto just
> from the names
>
> tap Comes from Ruby and a previous Groovy extension outside core
> exists; meant to conjure up the idea of tapping into an object
>
> autoWith Same as with but automatically returns self
>
> doWith Again, hard to distinguish between doWith and with from the
> names themselves
>
> tee An alternative name for tap
>
> auto A shortened version of 'autoWith'
>
> apply same as Kotlin which has copied Groovy's with but suffers
> from the downside that apply is already heavily overleaded in other
> contexts, e.g. functional programming
>
> withThis Distinction with normal with a bit subtle perhaps
>
> asThis Ditto
>
> within Ditto
>
> I'll also point out the 'identity' is currently an alias for 'with',
> in case that provides any additional inspiration.
>
> Perhaps you dis/like one of the above or have some other suggestions.
> Let us know.
>
>
> Cheers, Paul.
>
>
> [1] http://beust.com/weblog/2015/10/30/exploring-the-kotlin-standard-library/
