From dev-return-4394-archive-asf-public=cust-asf.ponee.io@groovy.apache.org Sat Mar 17 19:16:28 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 61DB7180652 for ; Sat, 17 Mar 2018 19:16:27 +0100 (CET) Received: (qmail 74014 invoked by uid 500); 17 Mar 2018 18:16:26 -0000 Mailing-List: contact dev-help@groovy.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@groovy.apache.org Delivered-To: mailing list dev@groovy.apache.org Received: (qmail 74004 invoked by uid 99); 17 Mar 2018 18:16:25 -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; Sat, 17 Mar 2018 18:16:25 +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 55858C012E for ; Sat, 17 Mar 2018 18:16:25 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.113 X-Spam-Level: *** X-Spam-Status: No, score=3.113 tagged_above=-999 required=6.31 tests=[HTML_MESSAGE=2, KAM_NUMSUBJECT=0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=1.313] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id ZeXDYh947CLp for ; Sat, 17 Mar 2018 18:16:22 +0000 (UTC) Received: from mx12lb.world4you.com (mx12lb.world4you.com [81.19.149.122]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 5E68B5F189 for ; Sat, 17 Mar 2018 18:16:21 +0000 (UTC) Received: from [84.112.214.51] (helo=[192.168.0.24]) by mx12lb.world4you.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.84_2) (envelope-from ) id 1exGNK-0003tB-7n; Sat, 17 Mar 2018 19:16:14 +0100 Subject: Re: [GEP]Lazy evaluation for Groovy 3 To: dev@groovy.apache.org, Suderman Keith References: <1521272109038-0.post@n5.nabble.com> <1521274102411-0.post@n5.nabble.com> <9FCB2E4A-C492-4139-9F44-06AE3B9ED62D@vassar.edu> From: MG Message-ID: <7481d552-6ade-a8a1-bab0-8b35f2e2da88@arscreat.com> Date: Sat, 17 Mar 2018 19:16:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <9FCB2E4A-C492-4139-9F44-06AE3B9ED62D@vassar.edu> Content-Type: multipart/alternative; boundary="------------5337D2456E6A30E3F2315550" Content-Language: en-US X-SA-Do-Not-Run: Yes X-AV-Do-Run: Yes X-SA-Exim-Connect-IP: 84.112.214.51 X-SA-Exim-Mail-From: mgbiz@arscreat.com X-SA-Exim-Scanned: No (on mx12lb.world4you.com); SAEximRunCond expanded to false This is a multi-part message in MIME format. --------------5337D2456E6A30E3F2315550 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Same here. Syntax would definitely clash with my existing code, is imho too concise / not obvious enough for a rare requirement. Wondering if this is important enough to consider doing this now (@Daniel: Am I right in assuming you want to get as much new syntax into 3.0 as possible ?-) ),  but think concept is worth expoloring in principle. From ther top of my hat: If we had support for parameters to methods being passed as an expression (as in C#) / not being evaluated, one could potentially write this based on that concept (but intrdoucing that would be an even bigger step) (?) In general I am a propenent of having powerful, general building blocks in a language, instead of specialized syntax for spezialized features. Otherwise (based on things already mentioned): 1. final records = proxy { doQueryFromDB() } // closure style 2. final records = proxy doQueryFromDB() // keyword style 3. final records = proxy(doQueryFromDB()) // function style 4. Something with @Lazy(proxy=true) ? Cheers, mg On 17.03.2018 14:21, Suderman Keith wrote: > +1 for the concept. > > -1 for using parenthesis.  As Andrew says, this introduces new > behaviour for parenthesis that I think violates the principle of least > surprise. > > Keith > >> On Mar 17, 2018, at 1:54 PM, Andrew Bayer > > wrote: >> >> Agreed - I don’t think this actually provides much, if any, real >> value, is syntactically confusing, and feels like it could cause some >> problems with existing code that assumes parentheses aren’t going to >> result in new behavior. >> >> A. >> >> On Sat, Mar 17, 2018 at 8:35 AM Cédric Champeau >> > wrote: >> >> -1, I also think this is confusing. >> >> 2018-03-17 13:30 GMT+01:00 Guillaume Laforge > >: >> >> I also find it confusing, in particular because it's not >> obvious, and there's some redundancy already with @Lazy (and >> Paolo has a good point as well as using closures are somewhat >> of a palliative as well) >> Perhaps we could think of ways to further improve / expand >> @Lazy perhaps? >> (rather than inventing something new / additional) >> >> On Sat, Mar 17, 2018 at 12:01 PM, Paolo Di Tommaso >> > > wrote: >> >> Frankly I found this confusing, it looks to me that the >> same concept can be implemented just using a closure. >> >> >> p >> >> On Sat, Mar 17, 2018 at 9:08 AM, Daniel.Sun >> > wrote: >> >> Hi Guillaume, >> >> I planed to generate proxy for lazy evaluation, so >> even if the reference of >> object is accessed, evaluation will not be triggered >> either, which is >> different from @Lazy >> >> Cheers, >> Daniel.Sun >> >> >> >> >> -- >> Sent from: >> http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html >> >> >> >> >> >> -- >> Guillaume Laforge >> Apache Groovy committer & PMC Vice-President >> Developer Advocate @ Google Cloud Platform >> >> Blog: http://glaforge.appspot.com/ >> Social: @glaforge  / Google+ >> >> >> > --------------5337D2456E6A30E3F2315550 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Same here.
Syntax would definitely clash with my existing code, is imho too concise / not obvious enough for a rare requirement.

Wondering if this is important enough to consider doing this now (@Daniel: Am I right in assuming you want to get as much new syntax into 3.0 as possible ?-) ),  but think concept is worth expoloring in principle.

From ther top of my hat:

If we had support for parameters to methods being passed as an expression (as in C#) / not being evaluated, one could potentially write this based on that concept (but intrdoucing that would be an even bigger step) (?)
In general I am a propenent of having powerful, general building blocks in a language, instead of specialized syntax for spezialized features.

Otherwise (based on things already mentioned):
  1. final records = proxy { doQueryFromDB() } // closure style
  2. final records = proxy doQueryFromDB() // keyword style
  3. final records = proxy(doQueryFromDB()) // function style
  4. Something with @Lazy(proxy=true) ?
Cheers,
mg



On 17.03.2018 14:21, Suderman Keith wrote:
+1 for the concept.

-1 for using parenthesis.  As Andrew says, this introduces new behaviour for parenthesis that I think violates the principle of least surprise.

Keith

On Mar 17, 2018, at 1:54 PM, Andrew Bayer <andrew.bayer@gmail.com> wrote:

Agreed - I don’t think this actually provides much, if any, real value, is syntactically confusing, and feels like it could cause some problems with existing code that assumes parentheses aren’t going to result in new behavior.

A.

On Sat, Mar 17, 2018 at 8:35 AM Cédric Champeau <cedric.champeau@gmail.com> wrote:
-1, I also think this is confusing.

2018-03-17 13:30 GMT+01:00 Guillaume Laforge <glaforge@gmail.com>:
I also find it confusing, in particular because it's not obvious, and there's some redundancy already with @Lazy (and Paolo has a good point as well as using closures are somewhat of a palliative as well)
Perhaps we could think of ways to further improve / expand @Lazy perhaps?
(rather than inventing something new / additional)

On Sat, Mar 17, 2018 at 12:01 PM, Paolo Di Tommaso <paolo.ditommaso@gmail.com> wrote:
Frankly I found this confusing, it looks to me that the same concept can be implemented just using a closure. 


p

On Sat, Mar 17, 2018 at 9:08 AM, Daniel.Sun <sunlan@apache.org> wrote:
Hi Guillaume,

I planed to generate proxy for lazy evaluation, so even if the reference of
object is accessed, evaluation will not be triggered either, which is
different from @Lazy

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html




--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform




--------------5337D2456E6A30E3F2315550--