Return-Path: X-Original-To: archive-asf-public-internal@cust-asf2.ponee.io Delivered-To: archive-asf-public-internal@cust-asf2.ponee.io Received: from cust-asf.ponee.io (cust-asf.ponee.io [163.172.22.183]) by cust-asf2.ponee.io (Postfix) with ESMTP id 0C7AB200BBD for ; Tue, 8 Nov 2016 16:09:40 +0100 (CET) Received: by cust-asf.ponee.io (Postfix) id 0AF64160B0A; Tue, 8 Nov 2016 15:09:40 +0000 (UTC) Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by cust-asf.ponee.io (Postfix) with SMTP id 05E0C160AFA for ; Tue, 8 Nov 2016 16:09:38 +0100 (CET) Received: (qmail 12725 invoked by uid 500); 8 Nov 2016 15:09:38 -0000 Mailing-List: contact users-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@groovy.apache.org Delivered-To: mailing list users@groovy.apache.org Received: (qmail 12715 invoked by uid 99); 8 Nov 2016 15:09:38 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 08 Nov 2016 15:09:38 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id A15A9C0748 for ; Tue, 8 Nov 2016 15:09:37 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 2.38 X-Spam-Level: ** X-Spam-Status: No, score=2.38 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-us.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id DYcsBdFSIWLZ for ; Tue, 8 Nov 2016 15:09:35 +0000 (UTC) Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53]) by mx1-lw-us.apache.org (ASF Mail Server at mx1-lw-us.apache.org) with ESMTPS id 2E0D35FC5F for ; Tue, 8 Nov 2016 15:09:35 +0000 (UTC) Received: by mail-wm0-f53.google.com with SMTP id a197so251380334wmd.0 for ; Tue, 08 Nov 2016 07:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FizxX0mOMaaLUXVlcEhTzXyIhVlftGAVpBLfKuNADZ4=; b=dtXson9jUwbzIuYQ4c+tU7IMKXHtyXg2x3abA8DObwCrwf7VvH5EEJl2kuEFmJMRcr +umf4APfuoXusoAznFhU2Qcnnp4tZlZ/FCLyd/AAy+VX2hOdvY5gdLRjI4ca/zm6lYeZ +AbFo5nqRoQwBkpQKrVBf0j1Hzb9LJukvQw5pMB5OC8acWCDjh0zra8tke1DcjR7ZKQI xd38IjVllOryDvoDyVyBq2eSvtzumW11/t6FgGzcVqIithpWaOK16G818L5AajUzkilf AMfLus19GZ7GH2ILlZY+O74DLEMnWR5Sng43M9hg+UzyUZVtIrH59ZGoDNEf0bHkf8Gx muOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FizxX0mOMaaLUXVlcEhTzXyIhVlftGAVpBLfKuNADZ4=; b=J5CZ5w5HdFvKGNXTYEqaa61/g7sLmaNZBA+SKwPFo9F5Juf4uqDCehbtNtTZFcwX26 /FX4+7sROoZ/eMjKPnQXyszz4d+Fhq1j7aXJMsoNMtxK+bykeJF0EzbCatYfruPHoI1f m4mK+ciFRZjlHH/nnJVKlcBzXWHTN+SOwnoq+qypcPMA8WrN86OF/ZSQZkBV0VLp9rdn 0CznzfJ2a5h6TnQCRaZT+EkyD1RrCGUUXnLw9IylnSS+7x923krNlP5+ZOEIf6wFadho qGYAnB/DxMIZ8xxdspmy3nd++tIU34Q7kzgzLQbVkM7iGBshidoOwVeW4dK3IHQIbxVE poOw== X-Gm-Message-State: ABUngveTvNR6T6iMqG5Meysp4RuH5ZKZ64A7fRAQrH8s9THhkAmRju5BwTljsDUNjiRbcodNsMjWs886bamrkQ== X-Received: by 10.28.130.66 with SMTP id e63mr9078584wmd.39.1478617754776; Tue, 08 Nov 2016 07:09:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.44.38 with HTTP; Tue, 8 Nov 2016 07:09:13 -0800 (PST) In-Reply-To: References: <0896240a-1214-f7f3-cd58-11c234e9c77d@gmail.com> From: Guillaume Laforge Date: Tue, 8 Nov 2016 16:09:13 +0100 Message-ID: Subject: Re: .with() variant that returns the original object To: users@groovy.apache.org Content-Type: multipart/alternative; boundary=001a1144364c083d450540cb86cd archived-at: Tue, 08 Nov 2016 15:09:40 -0000 --001a1144364c083d450540cb86cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable "having" makes me think too much of SQL, so it might be a bit misleading? On Tue, Nov 8, 2016 at 4:01 PM, Krzysztof Kowalczyk < kowalczyk.krzysztof@gmail.com> wrote: > Hi, > > What about "having": > > house.having { > windows.open() > }.having{ > doors.locked() > } > > car.having { wheels.having{ screws.allInPlace =3D true }} > > I guess withThis could be an alias (maybe even deprecated) so people woul= d > be able to find other method when they notice that returning this is sill= y. > > Regards, > Krzysztof > > On 8 November 2016 at 14:53, Kostas Saidis wrote: > >> +1 for tap. >> >> Alternatives don't seem to fit well. >> >> My proposal is touch. >> >> Example: >> >> assert [:].touch { >> a =3D 1 >> }.touch { >> b =3D 2 >> } =3D=3D [a:1, b:2] >> >> If you start touching the object, it is rather intuitive that you get th= e >> object itself as a result :) >> >> Cheers, >> Kostas >> >> PS: Some guys here may also like avec, perhaps? >> >> >> >> On 8/11/2016 4:34 =CE=BC=CE=BC, 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 =3D 1 >>> }.tap { >>> b =3D 2 >>> } =3D=3D [a:1, b:2] >>> >>> Or this one (adapted from a blog post[1] - and assuming you have a >>> config.properties file containing answer=3D42 as one of the properties)= : >>> >>> assert new Properties().tap { >>> new FileInputStream('config.properties').withCloseable { >>> load(it) >>> } >>> }.answer =3D=3D '42' >>> >>> Here are some of the names that have been suggested with some commentar= y: >>> >>> 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/ >>> >>> >> > --=20 Guillaume Laforge Apache Groovy committer & PMC Vice-President Developer Advocate @ Google Cloud Platform Blog: http://glaforge.appspot.com/ Social: @glaforge / Google+ --001a1144364c083d450540cb86cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
"having" makes me think too much of SQL, so it m= ight be a bit misleading?

On Tue, Nov 8, 2016 at 4:01 PM, Krzysztof Kowalczyk <kowalczyk.krzysztof@gmail.com> wrote:
Hi,

What about "having":<= br>
house.having {
=C2=A0 windows.open()
}.having{
=C2=A0 doors= .locked()
}

car.having { wheels.having{ screws.allInP= lace =3D true }}

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

Regards,
Krzysz= tof

On 8 November 2016 at 14:53, Kostas S= aidis <saikos@gmail.com> wrote:
+1 for tap.

Alternatives don't seem to fit well.

My proposal is touch.

Example:

assert [:].touch {
=C2=A0 =C2=A0 a =3D 1
}.touch {
=C2=A0 =C2=A0 b =3D 2
} =3D=3D [a:1, b:2]

 If you start touching the object, it is rather intuitive that you get the o= bject itself as a result :)

Cheers,
Kostas

PS: Some guys here may also like avec, perhaps?



On 8/11/2016 4:34 =CE=BC=CE=BC, 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<= /a>

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 num= erous 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<= br> examples since that is what the PR currently uses but we can easily
change that based on feedback.

myObject.tap {
=C2=A0 =C2=A0 =C2=A0// some code
}

is equivalent to:

myObject.with {
=C2=A0 =C2=A0 =C2=A0// some code
=C2=A0 =C2=A0 =C2=A0return this
}

Returning the 'self' object lends itself to various kinds of chaini= ng, e.g.

assert [:].tap {
=C2=A0 =C2=A0 =C2=A0a =3D 1
}.tap {
=C2=A0 =C2=A0 =C2=A0b =3D 2
} =3D=3D [a:1, b:2]

Or this one (adapted from a blog post[1] - and assuming you have a
config.properties file containing answer=3D42 as one of the properties):
assert new Properties().tap {
=C2=A0 =C2=A0 =C2=A0new FileInputStream('config.properties').w= ithCloseable {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0load(it)
=C2=A0 =C2=A0 =C2=A0}
}.answer =3D=3D '42'

Here are some of the names that have been suggested with some commentary:
doto=C2=A0 =C2=A0 Used by Clojure. Not camel case as per normal convention<= br> (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<= br> from the names

tap=C2=A0 =C2=A0 Comes from Ruby and a previous Groovy extension outside co= re
exists; meant to conjure up the idea of tapping into an object

autoWith=C2=A0 =C2=A0 Same as with but automatically returns self

doWith=C2=A0 =C2=A0Again, hard to distinguish between doWith and with from = the
names themselves

tee=C2=A0 =C2=A0 An alternative name for tap

auto=C2=A0 =C2=A0 A shortened version of 'autoWith'

apply=C2=A0 =C2=A0 same as Kotlin which has copied Groovy's with but su= ffers
from the downside that apply is already heavily overleaded in other
contexts, e.g. functional programming

withThis=C2=A0 =C2=A0 Distinction with normal with a bit subtle perhaps

asThis=C2=A0 =C2=A0 Ditto

within=C2=A0 =C2=A0 Ditto

I'll also point out the 'identity' is currently an alias for &#= 39;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/






--
=
=
Guillaume Laforge
Apache Groovy commit= ter & PMC Vice-President
Developer Advocate @ Goo= gle Cloud Platform

Blog:=C2=A0http://glaforge.appspot.com/
<= div>Social: @glaf= orge=C2=A0/ Google+
<= /div>
--001a1144364c083d450540cb86cd--