groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From C├ędric Champeau <cedric.champ...@gmail.com>
Subject Re: .with() variant that returns the original object
Date Tue, 08 Nov 2016 14:44:15 GMT
+1 to `tap`

2016-11-08 15:41 GMT+01:00 Guillaume Laforge <glaforge@gmail.com>:

> I quite like "tap" (like in wiretaping, you're looking through the pipe)
> We already have some rubyisms, so having one more is not a bad idea at all
> for consistency.
>
> "doto" doesn't really help me understand what the method is about.
>
> "apply" is too overloaded, for functional programming, etc, so I'd really
> avoid it.
>
> "tee" why not, but I didn't really knew what it was meanting.
>
> Not a big fan of auto, asThis, withThis or within.
>
> My preference clearly goes for tap!
>
> On Tue, Nov 8, 2016 at 3:34 PM, Paul King <paulk@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-stan
>> dard-library/
>>
>
>
>
> --
> Guillaume Laforge
> Apache Groovy committer & PMC Vice-President
> Developer Advocate @ Google Cloud Platform
>
> Blog: http://glaforge.appspot.com/
> Social: @glaforge <http://twitter.com/glaforge> / Google+
> <https://plus.google.com/u/0/114130972232398734985/posts>
>

Mime
View raw message