Hi,

What about "having":

house.having {
  windows.open()
}.having{
  doors.locked()
}

car.having { wheels.having{ screws.allInPlace = true }}

I guess withThis could be an alias (maybe even deprecated) so people would
be able to find other method when they notice that returning this is silly.

Regards,
Krzysztof

On 8 November 2016 at 14:53, Kostas Saidis <sai...@gmail.com> wrote:

> +1 for tap.
>
> Alternatives don't seem to fit well.
>
> My proposal is touch.
>
> Example:
>
> assert [:].touch {
>     a = 1
> }.touch {
>     b = 2
> } == [a:1, b:2]
>
> If you start touching the object, it is rather intuitive that you get the
> object itself as a result :)
>
> Cheers,
> Kostas
>
> PS: Some guys here may also like avec, perhaps?
>
>
>
> On 8/11/2016 4:34 μμ, Paul King 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/
>>
>>
>

Reply via email to