Re: Groovy Poster for Community Over Code EU

[Daniel Sun]

Nice work ;-)

On 2024/05/14 11:47:40 Paul King wrote:
> Hi folks,
> 
> We have a poster that will be displayed at Community Over Code EU in
> Bratislava in a few weeks.
> 
> Here is my current draft:
> 
> https://github.com/apache/apachecon-eu/blob/main/static/posters/CoCEU_WhyGroovyToday.pdf
> 
> There is a small window to make changes before they send the posters
> off to the printers. It will be printed I think on A1 size paper,
> about 594mm W x 841mm H (23.4 x 33.1 inches).
> 
> At the moment, it is rich in technical content - perhaps a little
> light in marketing the benefits. If I was to make changes I'd prefer
> to maybe reduce the first slightly and increase the latter. Let me
> know if you have any feedback.
> 
> Thanks, Paul.
> 

Re: [DISCUSS] EOL for Groovy 2.4.x

[Daniel Sun]

+1

Groovy 2.4.x is too old and lacks maintenance. It's strongly recommended to use 
Groovy 4+.

Cheers,
Daniel Sun

On 2024/06/28 02:08:57 Paul King wrote:
> Hi folks,
> 
> Groovy 2.4.x hasn't been something we have progressed for some time.
> The last "real" commit to the GROOVY_2_4_X branch and the last release
> (2.4.21) were both in Dec 2020.
> 
> For reference, 2.4.x supports back to JDK 1.6 while 2.5.x (which is
> not part of this discussion) supports back to JDK 1.7:
> https://groovy.apache.org/download.html#requirements
> 
> On the recommended page for GitHub security policy:
> https://github.com/apache/groovy/security/policy
> 
> We state:
> 2.4.x Only severe/critical vulnerabilities (*)
> (*) The 2.4.x stream is no longer the focus of the core team but
> critical security fixes or community contributions may lead to
> additional releases.
> 
> I propose to make the EOL official. I don't think the "weak support"
> will be good enough once CRA regulations come into play. My
> understanding from the CRA requirements is that we either intend to
> provide timely fixes for vulnerabilities for any supported version, or
> we should mark versions as EOL. This doesn't stop us from making an
> emergency fix/release if we chose, it just indicates that shouldn't be
> the expectation.
> 
> If anyone objects, please discuss here, otherwise I will create a VOTE
> thread in a few days.
> 
> Paul.
> 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free.www.avast.com
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 

Re: [DISCUSS] EOL for Groovy 2.4.x

[Daniel Sun]

> I would consider 2.5 for EOL as well

Good idea.

On 2024/06/28 12:38:54 Jochen Theodorou wrote:
> +1 out with it
> 
> I would consider 2.5 for EOL as well
> 
> > Hi folks,
> >
> > Groovy 2.4.x hasn't been something we have progressed for some time.
> > The last "real" commit to the GROOVY_2_4_X branch and the last release
> > (2.4.21) were both in Dec 2020.
> >
> > For reference, 2.4.x supports back to JDK 1.6 while 2.5.x (which is
> > not part of this discussion) supports back to JDK 1.7:
> > https://groovy.apache.org/download.html#requirements
> >
> > On the recommended page for GitHub security policy:
> > https://github.com/apache/groovy/security/policy
> >
> > We state:
> > 2.4.x Only severe/critical vulnerabilities (*)
> > (*) The 2.4.x stream is no longer the focus of the core team but
> > critical security fixes or community contributions may lead to
> > additional releases.
> >
> > I propose to make the EOL official. I don't think the "weak support"
> > will be good enough once CRA regulations come into play. My
> > understanding from the CRA requirements is that we either intend to
> > provide timely fixes for vulnerabilities for any supported version, or
> > we should mark versions as EOL. This doesn't stop us from making an
> > emergency fix/release if we chose, it just indicates that shouldn't be
> > the expectation.
> >
> > If anyone objects, please discuss here, otherwise I will create a VOTE
> > thread in a few days.
> >
> > Paul.
> >
> > 
> > Virus-free.www.avast.com
> > 
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> 
> 

Re: [VOTE] EOL for Groovy 2.4.x

[Daniel Sun]

+1 (binding)

Cheers,
Daniel Sun

On 2024/07/08 06:04:26 Paul King wrote:
> Hi folks,
> 
> As per the [DISCUSS] thread[1], there is strong consensus to EOL
> 2.4.x. Please vote to formalize this step.
> 
> [1] https://lists.apache.org/thread/ft6l7j331xxnj2sg1c2kz1mwz45mxyn3
> 
> My vote:
> +1 (binding)
> 
> Paul.
> 

Safe index for Groovy 3

[Daniel Sun]

Hi all,

  The new parser supports safe index now, which is proposed by Paul King
:)

  Here are some example code:

assert null == null?[1];
assert null == null?[1]?[1, 2];
assert null == null?[1]?[1, 2]?[1, 2, 3];

def a = null;
assert null == a?[1, 2];

def f() {return null}
assert null == f()?[1];

   More information can be found at the safeIndex branch of
groovy-parser
project(https://github.com/danielsun1106/groovy-parser/tree/safeIndex)

   Any thoughts?

   BTW, the antlr4 branch of apache/groovy is very old, I am going to
try to update it with the master.

Cheers,
Daniel.Sun





--
View this message in context: 
http://groovy.329449.n5.nabble.com/Safe-index-for-Groovy-3-tp5736558.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Safe index for Groovy 3

[Daniel Sun]

groovy-all-2.5.0-SNAPSHOT jar file used by groovy-parser is a bit outdated,
the following usual code can not be executed too(but it can be executed by
2.4.7...), so the static complication test cases will be added later :)

@CompileStatic
int cs() {
List a = [1, 2, 3]
return a[0];
}
cs();


Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Safe-index-for-Groovy-3-tp5736558p5736560.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Safe index for Groovy 3

[Daniel Sun]

Yeah, I like the idea too :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Safe-index-for-Groovy-3-tp5736558p5736562.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Safe index for Groovy 3

[Daniel Sun]

Hi OC,

   IMHO, 'full safe' switch  will change the semantic of existing '.',
which may reduce the maintainability and readability of program, so the
explicit '?' is necessary. Thanks for your suggestions :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Safe-index-for-Groovy-3-tp5736558p5736597.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

About the parrot branch of apache/groovy

[Daniel Sun]

Hi all,

 In order to not impact the existing branches as possible as I can,
I created a branch named "parrot" and put the new parser(Parrot) at the new
branch, which is based on antlr4 branch and synchronized the changes from
master. Currently there are 3 failed test cases waiting for
PR(https://github.com/apache/groovy/pull/443) to be merged.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About the parrot branch of apache/groovy

[Daniel Sun]

Hi Guillaume,

Currently I am not familiar with macro, so I will try to merge the PR into 
parrot branch and run test cases again.

Cheers,
Daniel.Sun




在 "Guillaume Laforge [via Groovy]" 
，2016年11月12日 上午12:20写道：

You can merge the PRs too? Are is there a particular issue with those?

On Fri, Nov 11, 2016 at 4:48 PM, Daniel Sun <[hidden email]> wrote:
Hi all,

 In order to not impact the existing branches as possible as I can,
I created a branch named "parrot" and put the new parser(Parrot) at the new
branch, which is based on antlr4 branch and synchronized the changes from
master. Currently there are 3 failed test cases waiting for
PR(https://github.com/apache/groovy/pull/443) to be merged.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722p5736723.html
To unsubscribe from About the parrot branch of apache/groovy, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736722&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjcyMnwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722p5736724.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About the parrot branch of apache/groovy

[Daniel Sun]

Hi Paul,

 I have not tried the groovyConsole on parrot before, but I'll verify the 
issue later ;)

PS: I am not beside my computer now.

Cheers,
Daniel.Sun



在 "paulk_asert [via Groovy]" 
，2016年11月12日 下午11:25写道：

Hi Daniel. Do you have any trouble  running the groovyConsole on the parrot 
branch? Won't start up for me. I'm travelling without access to proper 
internet. I might have just grabbed a snapshot at an inopportune time.

On 11 Nov 2016 8:35 PM, "Guillaume Laforge" <[hidden email]> wrote:
Ok, makes sense!

Le vendredi 11 novembre 2016, Daniel Sun <[hidden email]> a écrit :
Hi Guillaume,

Currently I am not familiar with macro, so I will try to merge the PR into 
parrot branch and run test cases again.

Cheers,
Daniel.Sun




在 "Guillaume Laforge [via Groovy]" ，2016年11月12日 
上午12:20写道：

You can merge the PRs too? Are is there a particular issue with those?

On Fri, Nov 11, 2016 at 4:48 PM, Daniel Sun <[hidden email]> wrote:
Hi all,

 In order to not impact the existing branches as possible as I can,
I created a branch named "parrot" and put the new parser(Parrot) at the new
branch, which is based on antlr4 branch and synchronized the changes from
master. Currently there are 3 failed test cases waiting for
PR(https://github.com/apache/groovy/pull/443) to be merged.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722p5736723.html
To unsubscribe from About the parrot branch of apache/groovy, click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


View this message in context: Re: About the parrot branch of 
apache/groovy<http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722p5736724.html>
Sent from the Groovy Dev mailing list 
archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at 
Nabble.com.


--
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>




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722p5736728.html
To unsubscribe from About the parrot branch of apache/groovy, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736722&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjcyMnwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722p5736729.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About the parrot branch of apache/groovy

[Daniel Sun]

Hi Paul,

 I used "gradlew -PuseAntlr4=true console" to launch groovyConsole. It's
OK for me now. Can you reproduce the issue?

  In addition, the groovyConsole uses the old parser even if option
"-PuseAntlr4=true" applied. I'll fix it later :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-parrot-branch-of-apache-groovy-tp5736722p5736730.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Negative relational operators for Groovy 3

[Daniel Sun]

Hi all,

  The new parser(Parrot) supports negative relational operators now,
which is proposed by Guillaume Laforge :)

  Here are some example
codes(https://github.com/danielsun1106/groovy-parser/blob/negativeRelationalOperators/src/test/resources/core/NegativeRelationalOperators_01x.groovy):

assert 'a' instanceof String
assert 'a' !instanceof Integer
assert 1 <= 2
assert 2 !<= 1
assert 2 >= 1
assert 1 !>= 2
assert 1 < 2
assert 2 !< 1
assert 2 > 1
assert 1 !> 2
assert 1 in [1, 2]
assert 3 !in [1, 2]

  The static compilation example codes can be found at
https://github.com/danielsun1106/groovy-parser/blob/negativeRelationalOperators/src/test/resources/core/NegativeRelationalOperators_02x.groovy

   Any thoughts?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: groovy parsers as subprojecs

[Daniel Sun]

Hi Jochen,

 The "I)" variant looks better than other variants, which works fine
now.

  BTW, glad to see you again in the mailing list :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/groovy-parsers-as-subprojecs-tp5736808p5736812.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Hi Jochen,

> oh... and one question... is "! in" the same as "!in"? 
Yeah, the negative relational operators are combined operators, which
will be transformed to normal NotExpression :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736813.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Hi Jochen,

>  I think !instanceof and !in are ok. The others... not sure here. Right 
>  now a*=b, which means !< is >=. And in this 
>  case I actually prefer >=. 

 Sometimes we write code like "!(a > b)", now we can write "a !> b"
instead, which is much close to our mind :)

Cheers,
Daniel.Sun





--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736816.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

OK. As most of us just like !in and !instanceof and prefer the sticky style, I 
will modify them later. Thanks for your review ;)

Cheers,
Daniel.Sun




在 "Guillaume Laforge [via Groovy]" 
，2016年11月18日 下午9:07写道：

On Fri, Nov 18, 2016 at 2:05 PM, Guillaume Laforge <[hidden email]> wrote:

On Fri, Nov 18, 2016 at 1:58 PM, Jochen Theodorou <[hidden email]> wrote:


On 18.11.2016 13:45, Daniel Sun wrote:
Hi all,

  The new parser(Parrot) supports negative relational operators now,
which is proposed by Guillaume Laforge :)

  Here are some example
codes(https://github.com/danielsun1106/groovy-parser/blob/negativeRelationalOperators/src/test/resources/core/NegativeRelationalOperators_01x.groovy):

assert 'a' instanceof String
assert 'a' !instanceof Integer
assert 1 <= 2
assert 2 !<= 1
assert 2 >= 1
assert 1 !>= 2
assert 1 < 2
assert 2 !< 1
assert 2 > 1
assert 1 !> 2
assert 1 in [1, 2]
assert 3 !in [1, 2]

I think !instanceof and !in are ok. The others... not sure here. Right now a=b, which means !< is >=. And in this case I actually 
prefer >=.

For instanceof and in, that's nice, but I think it's too cryptic for the other 
ones, which do exist in a different form, as currently !< is just >=, as Jochen 
says.

In terms of "groovy style", I think I'd prefer to have the ! sticking to in and 
instanceof.
It might also be less confusing to parse, should we some day add something like 
a factorial operator, or some other use for the !


--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736815.html
To unsubscribe from Negative relational operators for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736809&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjgwOXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736818.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

OK. I see :)



在 Cédric Champeau [via Groovy] 
，2016年11月18日 下午9:18写道：

I agree with Jochen and Guillaume: +1 to !instanceof and !in, but I don't like 
the other variants.

2016-11-18 14:11 GMT+01:00 Daniel Sun <[hidden email]>:
Hi Jochen,

>  I think !instanceof and !in are ok. The others... not sure here. Right
>  now a*=b, which means !< is >=. And in this
>  case I actually prefer >=.

 Sometimes we write code like "!(a > b)", now we can write "a !> b"
instead, which is much close to our mind :)

Cheers,
Daniel.Sun





--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736816.html
Sent from the Groovy Dev mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736817.html
To unsubscribe from Negative relational operators for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736809&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjgwOXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736819.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Hi Guillaume,

=== and !=== are available for Groovy 3, so "!is" is not necessary.

Currently only "!in" and "!instanceof" are supported with sticky style:
https://github.com/danielsun1106/groovy-parser/commit/69023a63446d14add54f43d3d7797c9dd2a7f903

If it is ok, I'll merge it into parrot branch of apache/groovy.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736830.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Interesting, haha :)



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736831.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

>  === and !=== are available for Groovy 3, so "!is" is not necessary.
 The identity operators should be === and !==:)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736834.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Hi Jochen,

 I've modified the implementation according to your suggestions that
ONLY support !in and !instanceof with sticky style. In addition, !in and
!instanceof are REAL operators
now(https://github.com/danielsun1106/groovy-parser/commit/87e2c41763422a6642414028d84efdccb90bfcda)

 I'll merge the feature into parrot branch of apache/groovy later if you
like it too :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736848.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Hi Jochen,

> "a !&& b" for a nand instead of "!(a && b)" or instead of "!a || !b" 
> then there is also ~& and !& 

Looks good. They've been added to my TODO list :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736849.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Hi Paul,

  You are right. Currently we just support !instanceof, !in. As to !is, we 
have !== instead in the Groovy 3.

Cheers,
Daniel.Sun



在 "paulk_asert [via Groovy]" 
，2016年11月18日 23:10写道：

On Sat, Nov 19, 2016 at 12:16 AM, Graeme Rocher <[hidden email]> wrote:
> In agreement with everyone else here.
>
> +1 to !in and !instanceof
> -1 to everything else

Same for me. I am undecided about sticky or not (allowing a space) but
easier to be conservative and loosen later.
I'm -1 for 'as' (no one has proposed it but another of our operators)
and probably 'is' too. If we do is, I don't see why we wouldn't do it
for all methods (that return boolean), e.g. assert 'a'.!isUpperCase()
and I am a little hesitant about such a notation.

Paul.

> On Fri, Nov 18, 2016 at 2:25 PM, Daniel Sun <[hidden email]> wrote:
>> OK. I see :)
>>
>>
>>
>> 在 Cédric Champeau [via Groovy] ，2016年11月18日
>> 下午9:18写道：
>>
>> I agree with Jochen and Guillaume: +1 to !instanceof and !in, but I don't
>> like the other variants.
>>
>> 2016-11-18 14:11 GMT+01:00 Daniel Sun <[hidden email]>:
>>>
>>> Hi Jochen,
>>>
>>> >  I think !instanceof and !in are ok. The others... not sure here. Right
>>> >  now a*=b, which means !< is >=. And in this
>>> >  case I actually prefer >=.
>>>
>>>  Sometimes we write code like "!(a > b)", now we can write "a !> b"
>>> instead, which is much close to our mind :)
>>>
>>> Cheers,
>>> Daniel.Sun
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context:
>>> http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736816.html
>>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>>
>>
>>
>>
>> 
>> If you reply to this email, your message will be added to the discussion
>> below:
>> http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736817.html
>> To unsubscribe from Negative relational operators for Groovy 3, click here.
>> NAML
>>
>>
>> 
>> View this message in context: Re: Negative relational operators for Groovy 3
>> Sent from the Groovy Dev mailing list archive at Nabble.com.
>
>
>
> --
> Graeme Rocher



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736824.html
To unsubscribe from Negative relational operators for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736809&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjgwOXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736853.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Hi Jochen,

 According to your proposals, I'm going to add the following operators:

1) !&&  a !&& b === !(a && b)
2) !||a !|| b === !(a || b)
3) !&  a !& b === !(a & b)
4) !|   a !| b === !(a | b)
5) ~& a ~& b === ~(a & b)
6) ~|  a ~| b === ~(a | b)

   Could you confirm whether the semantics of these operators are right
or not?

Thanks,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736882.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

[PROPOSAL]new operator ?=

[Daniel Sun]

Hi all,

 Marcin Erdmann proposed the new operator ?=, e.g.  a ?= "foo" is
equivalent of a = a ?: "foo". 

 I like his idea, what do you think about it?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/PROPOSAL-new-operator-tp5736886.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

回复： Re: [PROPOSAL]new operator ?=

[Daniel Sun]

Hi Jochen,

?= is similar with *=, +=, etc in their usage, and they are all for 
convenience and readability. So if ?= does not make sense, why others does?  :-P

a  = a * 2
a *= 2

a  = a ?: 2
a ?= 2

Cheers,
Daniel.Sun

--- 原始邮件 ---

发件人： "Jochen Theodorou [via Groovy]" 
已发： 2016年11月23日 上午12:47
收件人： "Daniel Sun" 
主题： Re: [PROPOSAL]new operator ?=




On 22.11.2016 15:25, Guillaume Laforge wrote:
> It's a feature that's often be requested.
> I think Ruby's got an equivalent with ||=, and it's often the reference
> people give when exploring our Elvis operator coming from a ruby
> background in particular.
> I've had several opportunities where I could've used this operator.
> It might make for a nice addition.

while I agree that ||= is more like what ruby offers we have the
problem, that for Groovy a||b always will be evaluated as boolean.

In fact first we apply groovy truth to a and if that is not true, we do
the same for b and if that is not true we return false, otherwise true.
Which means a = a||b would not be equal to a ||= b if that is supposed
to be the same as proposed for ?=.

What would come near to that is |, which is mapped to a method call to
"or". And then again, it has already a meaning for numbers, that does
not fit.

So for me a new operator makes more sense. But frankly...

> def foo(x) {
>   return x ?: "empty"
> }

or even

> def foo(x) {
>   x = x ?: "empty"
>   return x
> }

vs.

> def foo(x) {
>   x ?= "empty"
>   return x
> }

Is that really worth it? Does it really improve readability that much?
Or maybe someone has a better example?

it is different for !in and !instanceof, because of the spacing and
because you may have them in complex expressions. But ?= is a statement
and I would very much dislike this usage as expression.

For now I am -1 on this

bye Jochen




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/PROPOSAL-new-operator-tp5736886p5736900.html
To unsubscribe from [PROPOSAL]new operator ?=, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736886&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjg4NnwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Re-PROPOSAL-new-operator-tp5736906.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: [PROPOSAL]new operator ?=

[Daniel Sun]

Hi Jochen,

> Maybe we should start a vote of ?= or not... maybe on the user list... 
> then we see what people think. Daniel might have been a bit too fast here 
I'd like to start the vote of ?=;)

Just ask whether like it or not? Or like Andres's vote, ask which
operator do you like: 
1) ?=
2) ?:=
3) none

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/PROPOSAL-new-operator-tp5736886p5736922.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Negative relational operators for Groovy 3

[Daniel Sun]

Hi Guillaume,

  All features added in the new parser have been synch to parrot branch. I 
am looking for a better way to report missing the RIGHT parenthesis with less 
performance reduction ;)

Cheers,
Daniel.Sun



在 "Guillaume Laforge [via Groovy]" 
，2016年11月24日 上午6:14写道：

Ooops, a mistake of mine with a missing parens in some code before that.
We might have to pay attention to error reporting, and see how good it is to 
help fix developer's mistakes.

On Wed, Nov 23, 2016 at 10:47 PM, Guillaume Laforge <[hidden email]> wrote:
Is the "parrot" branch covering !in already?

I fetched it today, but got issues with !in

if (1 !in [0, 1, 2]) {}

Nov 23, 2016 10:45:29 PM org.apache.groovy.parser.antlr4.AstBuilder buildAST
SEVERE: Failed to build AST
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
ConsoleScript17: 11: Unexpected input: 'if'; Expecting RPAREN @ line 11, column 
1.
   if (1 !in [0, 1, 2]) {}
   ^

1 error

And

assert 3 !in []

Nov 23, 2016 10:45:50 PM org.apache.groovy.parser.antlr4.AstBuilder buildAST
SEVERE: Failed to build AST
org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
ConsoleScript18: 9: Unexpected input: 'assert'; Expecting RPAREN @ line 9, 
column 1.
   assert 3 !in []
   ^

1 error

I did build with -PuseAntlr4=true though.

Guillaume


On Fri, Nov 18, 2016 at 1:45 PM, Daniel Sun <[hidden email]> wrote:
Hi all,

  The new parser(Parrot) supports negative relational operators now,
which is proposed by Guillaume Laforge :)

  Here are some example
codes(https://github.com/danielsun1106/groovy-parser/blob/negativeRelationalOperators/src/test/resources/core/NegativeRelationalOperators_01x.groovy):

assert 'a' instanceof String
assert 'a' !instanceof Integer
assert 1 <= 2
assert 2 !<= 1
assert 2 >= 1
assert 1 !>= 2
assert 1 < 2
assert 2 !< 1
assert 2 > 1
assert 1 !> 2
assert 1 in [1, 2]
assert 3 !in [1, 2]

  The static compilation example codes can be found at
https://github.com/danielsun1106/groovy-parser/blob/negativeRelationalOperators/src/test/resources/core/NegativeRelationalOperators_02x.groovy

   Any thoughts?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



--
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>



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736964.html
To unsubscribe from Negative relational operators for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5736809&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNjgwOXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Negative-relational-operators-for-Groovy-3-tp5736809p5736968.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Proposal - Pattern matching elixir way

[Daniel Sun]

Hi Jorge,

  First of all, thanks for your proposal.

  I wonder why do you want the feature? What senarios make the code such
as "@When('!file || !new File(path).exists()')" overwhelm existing features
of groovy(e.g. switch statement)?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Proposal-Pattern-matching-elixir-way-tp5737005p5737008.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Elvis Assignment for Groovy 3

[Daniel Sun]

Hi all,

   The new parser "Parrot" supports Elvis Assignment(i.e.  ?=) now. Here
are some examples:

def a = 2
a ?= 1
assert a == 2

a = null
a ?= 1
assert a == 1

a = null
a ?= a ?= 1
assert a == 1

P.S. supports static compilation as well. 

Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Elvis-Assignment-for-Groovy-3-tp5737108.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Elvis Assignment for Groovy 3

[Daniel Sun]

My pleasure ;)

Cheers,
Daniel.Sun




在 "Marcin Erdmann [via Groovy]" 
，2016年12月3日 下午5:01写道：

Awesome, thanks for implementing it Daniel.

On Sat, Dec 3, 2016 at 7:59 AM, Daniel Sun <[hidden email]> wrote:
Hi all,

   The new parser "Parrot" supports Elvis Assignment(i.e.  ?=) now. Here
are some examples:

def a = 2
a ?= 1
assert a == 2

a = null
a ?= 1
assert a == 1

a = null
a ?= a ?= 1
assert a == 1

P.S. supports static compilation as well.

Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Elvis-Assignment-for-Groovy-3-tp5737108.html
Sent from the Groovy Dev mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Elvis-Assignment-for-Groovy-3-tp5737108p5737109.html
To unsubscribe from Elvis Assignment for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737108&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzEwOHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Elvis-Assignment-for-Groovy-3-tp5737108p5737114.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Elvis Assignment for Groovy 3

[Daniel Sun]

Thanks :)



在 "Guillaume Laforge [via Groovy]" 
，2016年12月3日 下午7:55写道：

Very cool!

On Sat, Dec 3, 2016 at 10:01 AM, Marcin Erdmann <[hidden email]> wrote:
Awesome, thanks for implementing it Daniel.

On Sat, Dec 3, 2016 at 7:59 AM, Daniel Sun <[hidden email]> wrote:
Hi all,

   The new parser "Parrot" supports Elvis Assignment(i.e.  ?=) now. Here
are some examples:

def a = 2
a ?= 1
assert a == 2

a = null
a ?= 1
assert a == 1

a = null
a ?= a ?= 1
assert a == 1

P.S. supports static compilation as well.

Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Elvis-Assignment-for-Groovy-3-tp5737108.html
Sent from the Groovy Dev mailing list archive at Nabble.com.




--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Elvis-Assignment-for-Groovy-3-tp5737108p5737111.html
To unsubscribe from Elvis Assignment for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737108&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzEwOHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Elvis-Assignment-for-Groovy-3-tp5737108p5737115.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Default Method for Groovy 3

[Daniel Sun]

Hi all,

 The new parser(Parrot) supports default method now. You can find
the new feature at  the enhancedInterface branch of groovy-parser project
  (
https://github.com/danielsun1106/groovy-parser/commit/89f45ac86e7945ef81283697b6ed9018e997a045
). If no problem with the implementation, I'll merge it into the master
later.

*Here is an example:*

interface Greetable {
String name();
default String hello() {
return 'hello'
}
}

class Person implements Greetable {
@Override
public String name() {
return 'Daniel'
}
}

def p = new Person()
assert 'hello, Daniel' == "${p.hello()}, ${p.name()}"

  *Another more complicated example can be found at:*
https://github.com/danielsun1106/groovy-parser/blob/enhancedInterface/src/test/resources/core/DefaultMethod_02x.groovy


Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Default Method for Groovy 3

[Daniel Sun]

Hi Rémi,

 As to the "default" modifier, we have to wait for the release of newer ASM 
to support it ;)

  Thanks for your reminding.

Cheers,
Daniel.Sun




在 "Remi Forax [via Groovy]" 
，2016年12月9日 上午4:38写道：

Hi Daniel,
as you have discovered, there is no flag for specifying a default method in the 
JVM spec, hence no ACC_DEFAULT flag in ASM,
a default method is just a non abstract method in an interface.

Also default and static methods in interface can be either public or private.

cheers,
Rémi

- Mail original -----
> De: "Daniel Sun" <[hidden email]>
> À: [hidden email]
> Envoyé: Jeudi 8 Décembre 2016 18:40:14
> Objet: Default Method for Groovy 3

> Hi all,
>
> The new parser(Parrot) supports default method now. You can find
> the new feature at  the enhancedInterface branch of groovy-parser project
> <https://github.com/danielsun1106/groovy-parser/tree/enhancedInterface>  (
> https://github.com/danielsun1106/groovy-parser/commit/89f45ac86e7945ef81283697b6ed9018e997a045
> ). If no problem with the implementation, I'll merge it into the master
> later.
>
> *Here is an example:*
>
> interface Greetable {
>String name();
>default String hello() {
>return 'hello'
>}
> }
>
> class Person implements Greetable {
>@Override
>public String name() {
>return 'Daniel'
>}
> }
>
> def p = new Person()
> assert 'hello, Daniel' == "${p.hello()}, ${p.name()}"
>
>  *Another more complicated example can be found at:*
> https://github.com/danielsun1106/groovy-parser/blob/enhancedInterface/src/test/resources/core/DefaultMethod_02x.groovy
>
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154p5737158.html
To unsubscribe from Default Method for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737154&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzE1NHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154p5737161.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Default Method for Groovy 3

[Daniel Sun]

Hi Rémi,
  I did not catch your words just now. That is great that we do not need 
wait for the release of ASM :)

Cheers,
Daniel.Sun



在 "Remi Forax [via Groovy]" 
，2016年12月9日 上午4:38写道：

Hi Daniel,
as you have discovered, there is no flag for specifying a default method in the 
JVM spec, hence no ACC_DEFAULT flag in ASM,
a default method is just a non abstract method in an interface.

Also default and static methods in interface can be either public or private.

cheers,
Rémi

- Mail original -----
> De: "Daniel Sun" <[hidden email]>
> À: [hidden email]
> Envoyé: Jeudi 8 Décembre 2016 18:40:14
> Objet: Default Method for Groovy 3

> Hi all,
>
> The new parser(Parrot) supports default method now. You can find
> the new feature at  the enhancedInterface branch of groovy-parser project
> <https://github.com/danielsun1106/groovy-parser/tree/enhancedInterface>  (
> https://github.com/danielsun1106/groovy-parser/commit/89f45ac86e7945ef81283697b6ed9018e997a045
> ). If no problem with the implementation, I'll merge it into the master
> later.
>
> *Here is an example:*
>
> interface Greetable {
>String name();
>default String hello() {
>return 'hello'
>}
> }
>
> class Person implements Greetable {
>@Override
>public String name() {
>return 'Daniel'
>}
> }
>
> def p = new Person()
> assert 'hello, Daniel' == "${p.hello()}, ${p.name()}"
>
>  *Another more complicated example can be found at:*
> https://github.com/danielsun1106/groovy-parser/blob/enhancedInterface/src/test/resources/core/DefaultMethod_02x.groovy
>
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> View this message in context:
> http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154p5737158.html
To unsubscribe from Default Method for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737154&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzE1NHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154p5737162.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Default Method for Groovy 3

[Daniel Sun]

It will be a good test case to cover :)

Cheers,
Daniel.Sun



在 "Marcin Erdmann [via Groovy]" 
，2016年12月9日 上午1:51写道：

That's great news. Not being able to use default interface methods, especially 
when working with libraries using them in Java code, felt limiting.

On Thu, 8 Dec 2016 at 17:40, Daniel Sun <[hidden email]> wrote:
Hi all,



 The new parser(Parrot) supports default method now. You can find

the new feature at  the enhancedInterface branch of groovy-parser project

<https://github.com/danielsun1106/groovy-parser/tree/enhancedInterface>  (

https://github.com/danielsun1106/groovy-parser/commit/89f45ac86e7945ef81283697b6ed9018e997a045

). If no problem with the implementation, I'll merge it into the master

later.



*Here is an example:*



interface Greetable {

String name();

default String hello() {

return 'hello'

}

}



class Person implements Greetable {

@Override

public String name() {

return 'Daniel'

}

}



def p = new Person()

assert 'hello, Daniel' == "${p.hello()}, ${p.name<http://p.name>()}"



  *Another more complicated example can be found at:*

https://github.com/danielsun1106/groovy-parser/blob/enhancedInterface/src/test/resources/core/DefaultMethod_02x.groovy





Cheers,

Daniel.Sun









--

View this message in context: 
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154.html

Sent from the Groovy Dev mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154p5737155.html
To unsubscribe from Default Method for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737154&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzE1NHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154p5737163.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Default Method for Groovy 3

[Daniel Sun]

Thanks ;)



在 "Guillaume Laforge [via Groovy]" 
，2016年12月9日 上午2:21写道：

Awesome!

On Thu, Dec 8, 2016 at 6:40 PM, Daniel Sun <[hidden email]> wrote:
Hi all,

 The new parser(Parrot) supports default method now. You can find
the new feature at  the enhancedInterface branch of groovy-parser project
<https://github.com/danielsun1106/groovy-parser/tree/enhancedInterface>  (
https://github.com/danielsun1106/groovy-parser/commit/89f45ac86e7945ef81283697b6ed9018e997a045
). If no problem with the implementation, I'll merge it into the master
later.

*Here is an example:*

interface Greetable {
String name();
default String hello() {
return 'hello'
}
}

class Person implements Greetable {
@Override
public String name() {
return 'Daniel'
}
}

def p = new Person()
assert 'hello, Daniel' == "${p.hello()}, ${p.name<http://p.name>()}"

  *Another more complicated example can be found at:*
https://github.com/danielsun1106/groovy-parser/blob/enhancedInterface/src/test/resources/core/DefaultMethod_02x.groovy


Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154p5737156.html
To unsubscribe from Default Method for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737154&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzE1NHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Default-Method-for-Groovy-3-tp5737154p5737164.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Welcome to our new committer : Sergei Egorov

[Daniel Sun]

Hi Sergei,

  Congratulations! I believe Groovy will be much more powerful because
of your endless effort :-)

Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Welcome-to-our-new-committer-Sergei-Egorov-tp5737173p5737178.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

About SimpleHTTPServer

[Daniel Sun]

Hi all,

  Does Groovy provide any function like Python's SimpleHTTPServer(e.g.
python -m SimpleHTTPServer 8000)?  If no similar module exits, I'd like to
implement one via Groovy 3(e.g. groovy -m SimpleHTTPServer 8000).

  FYI: https://docs.python.org/2/library/simplehttpserver.html

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

Yeah, I think so too, but I'm not sure whether Groovy already has some
similar function or not...

Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737196.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

Hi Remi,

   Your reply is always so helpful :-)
   As far as I remember, Sun introduced the http server in Java6. It's
lucky for us that it's included in the OpenJDK too.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737201.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

Hi Jochen,

   Given we have a directory containing some web pages and want to
access these pages via http protocal(e.g. we want to test WebRTC app), we
have to run a httpserver to provide http service. In the past, we have to
use Python to achieve the requirement because its SimpleHTTPServer is very
easy to use, just run "python -m SimpleHTTPServer 8000" to serve files of
current directory. As you know, my favorite programming language is Groovy,
so I want to find or implement similar function in Groovy :) 
If I implement it, I want to rely on NO 3rd part library(e.g.
netty). It's lucky that JDK provide a httpserver as Remi suggested. Groovy's 
SimpleHTTPServer can rely on it ;)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737203.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

Hi Sébastien,

 The SimpleHTTPServer will be implemented with NO 3rd part library, so
it will not impact existing production systems. In addition, it is
recommended to be used to provide http service for convenience(such as
testing WebRTC app). If we want to deploy our static web site, the
SimpleHTTPServer is not recommended to be used in production :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737205.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

Hi Paul,

  The built-in httpserver of JDK suggested by Remi seems better for us,
it is stable and does not require 3rd party library:
 
http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.httpserver/share/classes/com/sun/net/httpserver/package-info.java

  As to hooking to the existing socket server, I think it feasible as
mrhaki showed the relevant sample code, but we have to maintain it... so I
would like to implement SimpleHTTPServer based on the built-in httpserver.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737211.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

Thanks for your suggestion, mrhaki :)
In order to avoid maintaining the httpserver, I'd like to use the built-in
httpserver of JDK.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737213.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

Hi Cédric,

  It is also available in the openjdk, any potential problem with it?

http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/tip/src/jdk.httpserver/share/classes/com/sun/net/httpserver/package-info.java

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737214.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

That's great :)



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737216.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About SimpleHTTPServer

[Daniel Sun]

Hi Sébastien,

> My concern is that an HTTP server built into groovy would come with its 
> potential risks – even it is not used directly. 

  To be frank, I can not figure out... Could you tell me some exact
potential risks? 

> Having to redeploy an 
> app where groovy is embedded because of an issue with such a 
> non-critical feature would be somewhat... frustrating. 

  As such a feature is not core for a programming language, it will not
be updated frequently ;)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-SimpleHTTPServer-tp5737191p5737223.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

SimpleHTTPServer for Groovy 3( Maybe Groovy 2.5.0? )

[Daniel Sun]

Hi all,

SimpleHTTPServer has been implemented(http://bit.ly/2hsKm0V), it
supports serving files not only under directory but also in the zip file.
Here is the usage: "-lh  listen on a port and
provide http service", e.g.
*serve files under current directory*: groovy -lh 8000
*serve files under a specified directory*: groovy -lh 8000 d:\temp
*serve files in a zip file(we can view javadoc and groovydoc in the zip
files inspried by GroovyHelp)*: groovy -lh 8000 d:\apidoc.zip

 In addition, we can change the context root(/helloworld, default
context root is /) via passing complete arguments: groovy -lh 8000 d:\temp
helloworld,  its usage is: groovy -lh  
[context root]

 After the SimpleHTTPServer launched, we can access files via
visiting http://localhost://

 Any thoughts?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy-3-Maybe-Groovy-2-5-0-tp5737235.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: groovy git commit: Add option -lh to launch SimpleHTTPServer

[Daniel Sun]

Hi Paul,

 I agree with you, but in my fork(danielsun1106/groovy) contains many
exprimental commits and some failing build commits... I'm afraid these
commits will "pollute"  apache/groovy if I create PR and the PR merged. Any
advice?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Re-groovy-git-commit-Add-option-lh-to-launch-SimpleHTTPServer-tp5737234p5737237.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: SimpleHTTPServer for Groovy 3( Maybe Groovy 2.5.0? )

[Daniel Sun]

> groovy -m com.sparkjava:spark-groovy -c "serve(port: 8080, path:
'd:\\temp')"
How many characters will we type... to be frank, I am not that patient to
type such a long command.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy-3-Maybe-Groovy-2-5-0-tp5737235p5737238.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: SimpleHTTPServer for Groovy 3( Maybe Groovy 2.5.0? )

[Daniel Sun]

 Actually you can think of -lh as an extention of existing -l, the latter 
launches socket server and the former launches http server. We should have 
hooked http server function to the existing socket server, but maintaining a 
http server need much time and HR, so I implement it based on JDK built-in http 
server(NO 3rd party library) and use a separate option -lh.
 It is a practical function for many developers(especially for web app 
developers).

Cheers,
Daniel.Sun






在 2016年12月15日 上午1:48，"Marcin Erdmann [via Groovy]" 
写道：
-1 from me as well, fells more like a lib feature than a language feature. I 
agree with other folks that it is bloating the language for quite a narrow 
usecase.


On Wed, 14 Dec 2016 at 12:39, Sergei Egorov <[hidden 
email]> wrote:
Hi Daniel,

To be honest, I don't like it, -1 from me.

Why? Because we already put more and more stuff into the groovy itself, but, 
i.e. in a case of python, SimpleHTTPServer it's just a module after all.

I would rather see something like:

groovy -m com.sparkjava:spark-groovy -c "serve(port: 8080, path: 'd:\\temp')"

On Wed, Dec 14, 2016 at 2:29 PM Daniel Sun <[hidden 
email]> wrote:
Hi all,





SimpleHTTPServer has been implemented(http://bit.ly/2hsKm0V), it


supports serving files not only under directory but also in the zip file.


Here is the usage: "-lh  listen on a port and


provide http service", e.g.


*serve files under current directory*: groovy -lh 8000


*serve files under a specified directory*: groovy -lh 8000 d:\temp


*serve files in a zip file(we can view javadoc and groovydoc in the zip


files inspried by GroovyHelp)*: groovy -lh 8000 d:\apidoc.zip





 In addition, we can change the context root(/helloworld, default


context root is /) via passing complete arguments: groovy -lh 8000 d:\temp


helloworld,  its usage is: groovy -lh  


[context root]





 After the SimpleHTTPServer launched, we can access files via


visiting http://localhost://





 Any thoughts?





Cheers,


Daniel.Sun











--


View this message in context: 
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy-3-Maybe-Groovy-2-5-0-tp5737235.html


Sent from the Groovy Dev mailing list archive at Nabble.com.







If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy-3-Maybe-Groovy-2-5-0-tp5737235p5737243.html
To unsubscribe from SimpleHTTPServer for Groovy 3( Maybe Groovy 2.5.0? ), click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737235&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzIzNXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy-3-Maybe-Groovy-2-5-0-tp5737235p5737246.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: SimpleHTTPServer for Groovy 3( Maybe Groovy 2.5.0? )

[Daniel Sun]

Maybe we can use -m to specify the module instead of the convenient way -lh, 
e.g. groovy -m SimpleHTTPServer [base dir] [context root].

Thanks for your feedback.

Cheers,
Daniel.Sun



在 2016年12月15日 上午6:37，"Suderman Keith-3 [via Groovy]" 
写道：
> wrote:

groovy -m com.sparkjava:spark-groovy -c "serve(port: 8080, path:
'd:\\temp')"
How many characters will we type... to be frank, I am not that patient to
type such a long command.

That is what shell scripts are for, it is not a reason to include something in 
the core language.

Cheers,
Keith

On Dec 14, 2016, at 12:46 PM, Marcin Erdmann <[hidden 
email]> wrote:

-1 from me as well, fells more like a lib feature than a language feature. I 
agree with other folks that it is bloating the language for quite a narrow 
usecase.


On Wed, 14 Dec 2016 at 12:39, Sergei Egorov <[hidden 
email]> wrote:
Hi Daniel,

To be honest, I don't like it, -1 from me.

Why? Because we already put more and more stuff into the groovy itself, but, 
i.e. in a case of python, SimpleHTTPServer it's just a module after all.

I would rather see something like:

groovy -m com.sparkjava:spark-groovy -c "serve(port: 8080, path: 'd:\\temp')"

On Wed, Dec 14, 2016 at 2:29 PM Daniel Sun <[hidden 
email]> wrote:
Hi all,





SimpleHTTPServer has been implemented(http://bit.ly/2hsKm0V), it


supports serving files not only under directory but also in the zip file.


Here is the usage: "-lh  listen on a port and


provide http service", e.g.


*serve files under current directory*: groovy -lh 8000


*serve files under a specified directory*: groovy -lh 8000 d:\temp


*serve files in a zip file(we can view javadoc and groovydoc in the zip


files inspried by GroovyHelp)*: groovy -lh 8000 d:\apidoc.zip





 In addition, we can change the context root(/helloworld, default


context root is /) via passing complete arguments: groovy -lh 8000 d:\temp


helloworld,  its usage is: groovy -lh  


[context root]





 After the SimpleHTTPServer launched, we can access files via


visiting http://localhost<http://localhost/>://





 Any thoughts?





Cheers,


Daniel.Sun











--


View this message in context: 
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy-3-Maybe-Groovy-2-5-0-tp5737235.html


Sent from the Groovy Dev mailing list archive at Nabble.com<http://Nabble.com>.








If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy-3-Maybe-Groovy-2-5-0-tp5737235p5737245.html
To unsubscribe from SimpleHTTPServer for Groovy 3( Maybe Groovy 2.5.0? ), click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737235&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzIzNXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/SimpleHTTPServer-for-Groovy-3-Maybe-Groovy-2-5-0-tp5737235p5737247.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: groovy git commit: Add option -lh to launch SimpleHTTPServer

[Daniel Sun]

OK. I will revert them later.

Cheers,
Daniel.Sun




在 "Graeme Rocher-2 [via Groovy]" 
，2016年12月15日 15:49写道：

Agreed. "parrot" should be kept about the gramma and not adding new features.

Cheers


On Wed, Dec 14, 2016 at 1:49 PM, Daniel Sun <[hidden email]> wrote:

> Hi Paul,
>
>  I agree with you, but in my fork(danielsun1106/groovy) contains many
> exprimental commits and some failing build commits... I'm afraid these
> commits will "pollute"  apache/groovy if I create PR and the PR merged. Any
> advice?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: 
> http://groovy.329449.n5.nabble.com/Re-groovy-git-commit-Add-option-lh-to-launch-SimpleHTTPServer-tp5737234p5737237.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.



--
Graeme Rocher



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Re-groovy-git-commit-Add-option-lh-to-launch-SimpleHTTPServer-tp5737234p5737248.html
To unsubscribe from Re: groovy git commit: Add option -lh to launch 
SimpleHTTPServer, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737234&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzIzNHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Re-groovy-git-commit-Add-option-lh-to-launch-SimpleHTTPServer-tp5737234p5737250.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Gramma around annotations

[Daniel Sun]

Hi Graeme,

  It should be feasible in theory.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Gramma-around-annotations-tp5737249p5737255.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

About actor syntax for Groovy 3

[Daniel Sun]

Hi all,

  As we all know, GPars is awesome in concurrency programming. How about
introducing a new syntax for GPars's
actor(http://www.gpars.org/guide/guide/actors.html) to support concurrency
programming better like Erlang and
Scala(https://rocketeer.be/articles/concurrency-in-erlang-scala/)? We can
use <- to indicate sending messages(Erlang and Scala uses !). The initial
idea is shown as follows:

// groovy.actor.Actor extends groovyx.gpars.actor.DefaultActor
class Counter extends groovy.actor.Actor {
int counter = 0;

void act() {
react { int num ->
  ...
}
}
}

class ActorTest  {
def counter = new Counter()
counter.start()

for (i in 0 .. 10) {
counter <- i// send message to the counter actor
}
}

   Any thoughts?
  
Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About actor syntax for Groovy 3

[Daniel Sun]

class ActorTest  {
def counter = new Counter()
counter.start()

for (i in 0 .. 10) {
counter <- i// send message to the counter actor
}
} 

should be modified as:

class ActorTest  {
public static void main(String[] args) {
def counter = new Counter()
counter.start()

for (i in 0 .. 10) {
  counter <- i// send message to the counter actor
}
}
} 



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737575.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About actor syntax for Groovy 3

[Daniel Sun]

Hi Andres,

  If Scala was the sun, I wish Groovy was an eclipse ;)

  Maybe adding custom syntax for actor is not good idea for a programming 
language. But as a programming language, Groovy should learn good things from 
others to keep evolving and competitiveness. (like C# and Java)

Cheers,
Daniel.Sun



在 "Andres Almiray [via Groovy]" 
，2017年1月8日 上午1:28写道：

This is a slippery slope IMHO.

Adding custom syntax support in core for GPars might sound like a good idea 
given the fact that GPars is bundled with core. OTOH what about Spock, Grails, 
Ratpack and others? Wouldn't they benefit from custom syntax too? probably yes. 
Are they bundled with core? no, and they shouldn't.

My recommendation would be to prototype an AST transformation that can support 
the syntax, just like Spock does it.

One more thing, I would be very sad to see Groovy become a pale shade of Scala. 
Custom syntax and new operators are pushing Groovy in that direction.

Cheers
Andres

Sent from my primitive Tricorder

> On Jan 7, 2017, at 6:21 PM, Daniel Sun <[hidden email]> wrote:
>
> class ActorTest  {
>def counter = new Counter()
>counter.start()
>
>for (i in 0 .. 10) {
>counter <- i// send message to the counter actor
>}
> }
>
> should be modified as:
>
> class ActorTest  {
>public static void main(String[] args) {
>def counter = new Counter()
>counter.start()
>
>for (i in 0 .. 10) {
>  counter <- i// send message to the counter actor
>}
>}
> }
>
>
>
> --
> View this message in context: 
> http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737575.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737576.html
To unsubscribe from About actor syntax for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737574&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzU3NHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737581.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About actor syntax for Groovy 3

[Daniel Sun]

Yeah, << is a better choice ;)



在 Jesper Steen Møller [via Groovy] 
，2017年1月8日 上午1:31写道：

But

Wouldn’t << be a natural choice which would work today?

-Jesper

> On 7 Jan 2017, at 18.16, Daniel Sun <[hidden email]> wrote:
>
> Hi all,
>
>  As we all know, GPars is awesome in concurrency programming. How about
> introducing a new syntax for GPars's
> actor(http://www.gpars.org/guide/guide/actors.html) to support concurrency
> programming better like Erlang and
> Scala(https://rocketeer.be/articles/concurrency-in-erlang-scala/)? We can
> use <- to indicate sending messages(Erlang and Scala uses !). The initial
> idea is shown as follows:
>
> // groovy.actor.Actor extends groovyx.gpars.actor.DefaultActor
> class Counter extends groovy.actor.Actor {
>int counter = 0;
>
>void act() {
>react { int num ->
>  ...
>}
>}
> }
>
> class ActorTest  {
>def counter = new Counter()
>counter.start()
>
>for (i in 0 .. 10) {
>counter <- i// send message to the counter actor
>}
> }
>
>   Any thoughts?
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: 
> http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737577.html
To unsubscribe from About actor syntax for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737574&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzU3NHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737582.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About actor syntax for Groovy 3

[Daniel Sun]

As Andres pointed, it is better for GPars to have its own DSL.

Cheers,
Daniel.Sun



在 "jnorthr [via Groovy]" ，2017年1月8日 
上午1:35写道：

Russel is working on GPars v2.0 so have asked him if this proposed change is 
do-able.

On 7 January 2017 at 18:28, Andres Almiray <[hidden email]> wrote:
This is a slippery slope IMHO.

Adding custom syntax support in core for GPars might sound like a good idea 
given the fact that GPars is bundled with core. OTOH what about Spock, Grails, 
Ratpack and others? Wouldn't they benefit from custom syntax too? probably yes. 
Are they bundled with core? no, and they shouldn't.

My recommendation would be to prototype an AST transformation that can support 
the syntax, just like Spock does it.

One more thing, I would be very sad to see Groovy become a pale shade of Scala. 
Custom syntax and new operators are pushing Groovy in that direction.

Cheers
Andres

Sent from my primitive Tricorder

> On Jan 7, 2017, at 6:21 PM, Daniel Sun <[hidden email]> wrote:
>
> class ActorTest  {
>def counter = new Counter()
>counter.start()
>
>for (i in 0 .. 10) {
>counter <- i// send message to the counter actor
>}
> }
>
> should be modified as:
>
> class ActorTest  {
>public static void main(String[] args) {
>def counter = new Counter()
>counter.start()
>
>for (i in 0 .. 10) {
>  counter <- i// send message to the counter actor
>}
>}
> }
>
>
>
> --
> View this message in context: 
> http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737575.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737578.html
To unsubscribe from About actor syntax for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737574&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzU3NHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737583.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About actor syntax for Groovy 3

[Daniel Sun]

Hi Jochen,

   I'm looking for a new syntax for concurrency programming, which
should be able to hide complex for developers. As you said, the actor syntax
is not necessary. I agree with you, because it just replaces 'send' method
with '<<', but I wish the topic could let us think about the concurrency
programming syntax.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-actor-syntax-for-Groovy-3-tp5737574p5737598.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: next releases

[Daniel Sun]

Hi Paul,

  Will the new parser Parrot be included in 2.5.x releases as an
optional parser? If developers want to give it a try, just turn on the
switch "-Dgroovy.antlr4=true".

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/next-releases-tp5737758p5737761.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: next releases

[Daniel Sun]

Hi Andres,

> I'd suggest to release 2.5.0-beta and 3.0-ea together. Just like the JDK
> team has been posting JDK9 EA releases, we could do the same. We know for
> a fact we're going to break things, so let's make sure the public has
> ample time to test out the changes.

  I like your idea :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/next-releases-tp5737758p5737772.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

答复: next releases

[Daniel Sun]

Hi Thibault,

  The new parser Parrot passes all test cases of Apache Groovy 
project(including shouldFail test cases), and the AST generated by Parrot is 
identical to the AST generated by the old one except for the AST node 
position(Parrot provides more accurate position information). If we think 
passing all test cases and owning identical AST as the checking standard, we 
could say Parrot is compatible with the old parser ??

   BTW, some syntax which does not conform to the GLS(i.e. wild syntax) 
could not be covered, so Parrot was tested via some main Groovy projects, e.g. 
Grails, Gradle, Spock, Geb. But we are not sure Parrot can cover all *wild* 
syntax...

Cheers,
Daniel.Sun

发件人: Thibault Kruse [via 
Groovy]<mailto:ml-node+s329449n5737781...@n5.nabble.com>
发送时间: 2017年1月18日 6:46
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: next releases

Alternatively, groovy-antlr4 could be a separate jar.

If I understand correctly, then we are very confident that the new parser 
accepts all programs that the old parser accepted, because that is easy to 
test. But we do not know if it rejects all programs that the old parser 
rejected, because that is difficult to test. This is no small risk, is it? 
Users will have to be testers.


On Jan 17, 2017 5:57 PM, "S?ren Berg Glasius" <[hidden 
email]> wrote:
Can the parrot be packaged as separate jar that can be a dependency? That way 
it can be included at will

On Tue, 17 Jan 2017 at 09:56 Guillaume Laforge <[hidden 
email]> wrote:
This is a beta, not the final release, though.

On Tue, Jan 17, 2017 at 9:54 AM, Cédric Champeau <[hidden 
email]> wrote:
I'm reluctant on adding the experimental parser in a release. It requires a 
different version of antlr, which means more dependencies than we really need. 
We should keep the distribution as clean as possible. Not saying that the new 
parser is dirty, but that the size and dependencies of the distribution should 
remain as small as possible.

2017-01-17 9:48 
GMT+01:00 Daniel Sun <[hidden 
email]>:
Hi Paul,

  Will the new parser Parrot be included in 2.5.x releases as an
optional parser? If developers want to give it a try, just turn on the
switch "-Dgroovy.antlr4=true".

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/next-releases-tp5737758p5737761.html
Sent from the Groovy Dev mailing list archive at Nabble.com.




--
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>
--
Best regards / Med venlig hilsen,
S?ren Berg Glasius

Hedevej 1, Gl. Rye, 8680 Ry, Denmark
Mobile: +45 40 44 91 88, Skype: sbglasius
--- Press ESC once to quit - twice to save the changes.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/next-releases-tp5737758p5737781.html
To unsubscribe from next releases, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737758&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzc1OHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/next-releases-tp5737758p5737783.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

答复: next releases

[Daniel Sun]

Hi Paul,

  OK. I understand others’s fears ??
  Maybe releasing 3.0.0-ea and 2.5.0-beta together suggested by Andres is 
feasible.

Cheers,
Daniel.Sun

发件人: paulk_asert [via Groovy]<mailto:ml-node+s329449n5737780...@n5.nabble.com>
发送时间: 2017年1月18日 6:42
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: next releases

Hi Daniel,

Other comments have kind of superseded this one. The only thing I'll
add is that I am not averse to finding a way to let 2.5 users try the
new parser somehow - but as Cédric said, not at the expensive of
overcomplicating our normal release.

Cheers, Paul.


On Tue, Jan 17, 2017 at 6:48 PM, Daniel Sun <[hidden 
email]> wrote:

> Hi Paul,
>
>   Will the new parser Parrot be included in 2.5.x releases as an
> optional parser? If developers want to give it a try, just turn on the
> switch "-Dgroovy.antlr4=true".
>
> Cheers,
> Daniel.Sun
>
>
>
> --
> View this message in context: 
> http://groovy.329449.n5.nabble.com/next-releases-tp5737758p5737761.html
> Sent from the Groovy Dev mailing list archive at Nabble.com.



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/next-releases-tp5737758p5737780.html
To unsubscribe from next releases, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737758&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzc1OHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/next-releases-tp5737758p5737784.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

The order of modifiers and annotations

[Daniel Sun]

Hi all,

   Currently the old parser allows mixing modifiers and annotations,
e.g.

*Current*
@interface Test1 {}
@interface Test2 {}
@Test1 final @Test2 a

*Suggested*
@interface Test1 {}
@interface Test2 {}
@Test1 @Test2 final a

 In addition, the order of modifiers is arbitrary too, e.g.

*Current*
class A {
static final public a
}

*Suggested*
class A {
public static final a
}

 I wonder it is feature of Groovy or some space we should
improve(e.g. check more strictly)?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: The order of modifiers and annotations

[Daniel Sun]

Should we check the redundant modifiers? e.g.

*Current*
class A {
private def a  // def is redundant. IMHO, I really don't like it...
}

*Suggested*
class A {
private a 
}

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737809.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: The order of modifiers and annotations

[Daniel Sun]

> def is by now to be thought of as an alias for Object
OK. I see. Thanks :)


Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737813.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: The order of modifiers and annotations

[Daniel Sun]

I'll take a look at the issue later.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737818.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: The order of modifiers and annotations

[Daniel Sun]

I verified that the new parser Parrot does not have the issue( GROOVY-4757
  ), the following test
case was added in the parrot branch. And I'll resolve the JIRA issue later.

https://github.com/apache/groovy/commit/348465a1b193703c43aafeaabf2b286657d8493b


Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737824.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: The order of modifiers and annotations

[Daniel Sun]

You're welcome :)



--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737826.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

The priority of .. and . (GROOVY-3240)

[Daniel Sun]

Hi all,

  I'm taking a look at  GROOVY-3240
  , which was raised by
me some years ago. I wonder whether .. has higher priority than DOT(.) or
not.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-priority-of-and-GROOVY-3240-tp5737831.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: The priority of .. and . (GROOVY-3240)

[Daniel Sun]

OK. I will close the issue later.

Cheers,
Daniel.Sun



在 "Guillaume Laforge [via Groovy]" 
，2017年1月19日 20:36写道：

Currently .. and ..< have lower priority than .
Not sure we should revisit that, it would be a useless breaking change.

Integer.metaClass.foo = { delegate + 1 }
assert 3.foo()..4.foo() == 4..5
​
​

On Thu, Jan 19, 2017 at 1:25 PM, Daniel Sun <[hidden email]> wrote:
Hi all,

  I'm taking a look at  GROOVY-3240
<https://issues.apache.org/jira/browse/GROOVY-3240>  , which was raised by
me some years ago. I wonder whether .. has higher priority than DOT(.) or
not.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-priority-of-and-GROOVY-3240-tp5737831.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/The-priority-of-and-GROOVY-3240-tp5737831p5737834.html
To unsubscribe from The priority of .. and . (GROOVY-3240), click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737831&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzgzMXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-priority-of-and-GROOVY-3240-tp5737831p5737840.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: The order of modifiers and annotations

[Daniel Sun]

Thanks :)



在 "Marcin Erdmann [via Groovy]" 
，2017年1月20日 下午5:09写道：

Awesome!

On Thu, Jan 19, 2017 at 11:01 AM, Daniel Sun <[hidden email]> wrote:
I verified that the new parser Parrot does not have the issue( GROOVY-4757
<https://issues.apache.org/jira/browse/GROOVY-4757>  ), the following test
case was added in the parrot branch. And I'll resolve the JIRA issue later.

https://github.com/apache/groovy/commit/348465a1b193703c43aafeaabf2b286657d8493b


Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737824.html
Sent from the Groovy Dev mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737886.html
To unsubscribe from The order of modifiers and annotations, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737808&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzgwOHwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/The-order-of-modifiers-and-annotations-tp5737808p5737887.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

About array initializer of Java style for Groovy 3

[Daniel Sun]

Hi all,

   Java supports specifing initial values while creating arrays, e.g.
`new int[] {1, 2, 3}`, `new String[] { hello(), world() }`, etc. I plan to
add this syntax for Groovy 3 to improve the compatibility between Groovy and
Java. 

   Any thoughts?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About array initializer of Java style for Groovy 3

[Daniel Sun]

Hi Andres,

   Parrot can parse ` def a = {1, 2, 3}` properly, but it can not parse
`{1, 2, 3}`, which is not supported by Java too.

   This is the initial implementation :)
https://github.com/danielsun1106/groovy-parser/commit/96e6c923a4d09d48448f8731a314c918ee6c0e7c


Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737944.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About array initializer of Java style for Groovy 3

[Daniel Sun]

closure



在 "Guillaume Laforge [via Groovy]" 
，2017年1月24日 16:54写道：

What happens for def a = { 2 }, is it parsed as a closure or an array 
initializer?

On Tue, Jan 24, 2017 at 9:52 AM, Daniel Sun <[hidden email]> wrote:
Hi Andres,

   Parrot can parse ` def a = {1, 2, 3}` properly, but it can not parse
`{1, 2, 3}`, which is not supported by Java too.

   This is the initial implementation :)
https://github.com/danielsun1106/groovy-parser/commit/96e6c923a4d09d48448f8731a314c918ee6c0e7c


Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737944.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737945.html
To unsubscribe from About array initializer of Java style for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737941&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzk0MXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737946.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About array initializer of Java style for Groovy 3

[Daniel Sun]

or we just support new int[] {1,2,3}  ？



在 "Guillaume Laforge [via Groovy]" 
，2017年1月24日 16:54写道：

What happens for def a = { 2 }, is it parsed as a closure or an array 
initializer?

On Tue, Jan 24, 2017 at 9:52 AM, Daniel Sun <[hidden email]> wrote:
Hi Andres,

   Parrot can parse ` def a = {1, 2, 3}` properly, but it can not parse
`{1, 2, 3}`, which is not supported by Java too.

   This is the initial implementation :)
https://github.com/danielsun1106/groovy-parser/commit/96e6c923a4d09d48448f8731a314c918ee6c0e7c


Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737944.html
Sent from the Groovy Dev mailing list archive at Nabble.com.



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737945.html
To unsubscribe from About array initializer of Java style for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737941&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzk0MXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737947.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About array initializer of Java style for Groovy 3

[Daniel Sun]

+1



在 "Guillaume Laforge [via Groovy]" 
，2017年1月24日 下午5:19写道：

Good point.
We should definitely avoid confusion as much as possible, and avoid introducing 
ambiguities.

On Tue, Jan 24, 2017 at 10:12 AM, Andres Almiray <[hidden email]> wrote:
I think we should support only explicit array initilization with array type, 
that is "new int[] { 2 }" for compatibility's sake.

Sent from my iPhone

On 24 Jan 2017, at 09:59, Daniel Sun <[hidden email]> wrote:

or we just support new int[] {1,2,3}  ？



在 "Guillaume Laforge [via Groovy]" ，2017年1月24日 16:54写道：

What happens for def a = { 2 }, is it parsed as a closure or an array 
initializer?

On Tue, Jan 24, 2017 at 9:52 AM, Daniel Sun <[hidden email]> wrote:
Hi Andres,

   Parrot can parse ` def a = {1, 2, 3}` properly, but it can not parse
`{1, 2, 3}`, which is not supported by Java too.

   This is the initial implementation :)
https://github.com/danielsun1106/groovy-parser/commit/96e6c923a4d09d48448f8731a314c918ee6c0e7c


Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737944.html
Sent from the Groovy Dev mailing list archive at Nabble.com<http://Nabble.com>.



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737945.html
To unsubscribe from About array initializer of Java style for Groovy 3, click 
here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


View this message in context: Re: About array initializer of Java style for 
Groovy 
3<http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737947.html>
Sent from the Groovy Dev mailing list 
archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at 
Nabble.com<http://Nabble.com>.



--
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>



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737949.html
To unsubscribe from About array initializer of Java style for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737941&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzk0MXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737950.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About array initializer of Java style for Groovy 3

[Daniel Sun]

Hi Rémi,

  The improvement has been completed in my groovy-parser repository, it
is being tested now. I'll sync them to parrot branch of apache/groovy later
:)

  Thanks for your clear explanation and advice!

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-array-initializer-of-Java-style-for-Groovy-3-tp5737941p5737953.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Array initializer of Java style for Groovy 3

[Daniel Sun]

Hi all,

  The new parser Parrot support array initializer of Java style, e.g.
new int[] {1, 2, 3}, new int[][]{new int[]{1, 1.plus(1)}, new int[]
{2.plus(1), 4}}, new String[] {'hello', 'world'}

  More examples can be found at
https://github.com/danielsun1106/groovy-parser/blob/master/src/test/resources/core/Array_01x.groovy

   If you want to give it a try, follow the steps to launch groovy
console to run your code:

$ git clone https://github.com/danielsun1106/groovy-parser.git
$ cd groovy-parser
$ ./gradlew groovyConsole


Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Array-initializer-of-Java-style-for-Groovy-3-tp5737955.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

答复: Array initializer of Java style for Groovy 3

[Daniel Sun]

Thanks ??

发件人: Cédric Champeau [via 
Groovy]<mailto:ml-node+s329449n5737956...@n5.nabble.com>
发送时间: 2017年1月24日 20:18
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: Array initializer of Java style for Groovy 3

Great work!

2017-01-24 13:12 GMT+01:00 Daniel Sun <[hidden 
email]>:
Hi all,

  The new parser Parrot support array initializer of Java style, e.g.
new int[] {1, 2, 3}, new int[][]{new int[]{1, 1.plus(1)}, new int[]
{2.plus(1), 4}}, new String[] {'hello', 'world'}

  More examples can be found at
https://github.com/danielsun1106/groovy-parser/blob/master/src/test/resources/core/Array_01x.groovy

   If you want to give it a try, follow the steps to launch groovy
console to run your code:

$ git clone https://github.com/danielsun1106/groovy-parser.git
$ cd groovy-parser
$ ./gradlew groovyConsole


Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Array-initializer-of-Java-style-for-Groovy-3-tp5737955.html
Sent from the Groovy Dev mailing list archive at Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/Array-initializer-of-Java-style-for-Groovy-3-tp5737955p5737956.html
To unsubscribe from Array initializer of Java style for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5737955&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczNzk1NXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/Array-initializer-of-Java-style-for-Groovy-3-tp5737955p5737957.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Parrot and the ++ and -- operators

[Daniel Sun]

Hi Joe,

  I've added your sample code as test
cases(https://github.com/danielsun1106/groovy-parser/commit/9914682e53fb2fe3d4bb335c8153e61066cea317).
Parrot has same result with the old parser ;)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Parrot-and-the-and-operators-tp5737960p5737973.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

[Daniel Sun]

Hi  Cédric,

>  having a protected property just cannot work
Could you tell me why trait does not support protected property?

Thanks,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738019.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: release process

[Daniel Sun]

Hi Jesper,

> I recognise that the Antlr4 parser AST building looks really neat in Java
> 8, but easthetics aside
That's why I choose Java 8 to rewrite the parser :)

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/release-process-tp5737841p5738020.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

[Daniel Sun]

OK. I see. Thanks :)

BTW, the interface with default methods is based on Traits, I found Traits
does not support static methods too... So maybe we should generate bytecode
for default methods and static methods of interface as Java 8 do.

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738022.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

[Daniel Sun]

Hi Graeme,

 Here is my test code, which fails:

trait A {
public static String m() { return '123' }
}

A.m()

error messages:

groovy.lang.MissingMethodException: No signature of method: static A.m() is
applicable for argument types: () values: []
Possible solutions: is(java.lang.Object), any(), dump(),
any(groovy.lang.Closure), use([Ljava.lang.Object;), tap(groovy.lang.Closure)

at ConsoleScript7.run(ConsoleScript7:5)



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738025.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

[Daniel Sun]

Hi  Cédric,

> oh and that's written in the docs
Groovy's documentation is so detail... it's hard for me to believe ;)

BTW, Java 8 supports static methods and default methods in the interfaces,
how about refining the implementation of traits based on the enhanced
interfaces? then traits can have its own static methods and method
implementation(based on the default method).

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738028.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: Traits and protected properties

[Daniel Sun]

Hi Cédric,

 As far as I remember, Groovy 3+ will require Java 8. So maybe we could
upgrade the default version of class file to Java 8+ in Groovy 3+ releases?

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/Traits-and-protected-properties-tp5738002p5738031.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

About the "implies" operator(GROOVY-2576)

[Daniel Sun]

Hi all,

  The "implies" operator "=>" was suggested many years ago, here is the
replated JIRA issue( GROOVY-2576
  ) . 

  Do you want it for Groovy 3? (+1: yes; -1: no; 0: not bad)

  BTW, recently I have been going through the issues related to the old
parser, many issues existing for many years do not exist in the new parser
Parrot :) 

Cheers,
Daniel.Sun



--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: About the "implies" operator(GROOVY-2576)

[Daniel Sun]

Hi Jochen,

  Thanks for your analysis in detail :)

   => is a very expressive operator. if we could implement it as 
+(corresponding to plus method) does and apply different business logic when 
necessary, it would be much more useful. And the default implementation of 
"implies" method can be "!a||b".

As to the association of the operator, I prefer the left association, 
i.e. a => b => c is equivalent to (a => b) => c.

   The above is the initial plan to implement the  "implies" operator.

Cheers,
Daniel.Sun


在 2017年1月26日 上午3:20，"Jochen Theodorou [via Groovy]"  Hi all,
>
>The "implies" operator "=>" was suggested many years ago, here is the
> replated JIRA issue( GROOVY-2576
>   ) .
>
>Do you want it for Groovy 3? (+1: yes; -1: no; 0: not bad)
>
>BTW, recently I have been going through the issues related to the old
> parser, many issues existing for many years do not exist in the new parser
> Parrot :)

If we do this (and I say +1) we should clear some things:
1) what does a=>b=>c mean, since (a=>b)=>c is not the same as a=>(b=>c)
2) use groovy truth and when to apply it? If we map a=>b to !a||b, then
it will use Groovy truth on a and b, but if we map to an implies method
it will get a and b, use groovy truth on them or not and we then maybe
use groovy truth on the result. I personally would be for not using
groovy truth here, thus make it more in line with | and &.
3) if a=>b is mapped to !a||b we will evaluate a, negate it, and
depending on the result maybe never evaluate b. As long as a and b are
free of side effects, that does not play an extremely important role,
but if we map it to a method a and b will be evaluated always. If we
would say it is more like !a|b, which would also require both being
evaluated, then there is still the fact that !a ensures we call here
always the boolean or function, never one defined by an arbitrary a
4) instead of using !a, which converts a to a boolean and negates it, we
can also use ~a, which is a binary negate also working on booleans, but
not converting a to a boolean if it is no boolean. Here we have to
especially think about ~a|b calling "or" on a Pattern if a is a String.
Also not many things besides boolean and numbers really support
something useful of the binary negate.

I mention those points so we can make a proper specification for the
behaviour of this operator ;)

bye Jochen



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738042.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click 
here.
NAML




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738043.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

One more new operator "implies" ( => ) for Groovy 3

[Daniel Sun]

Hi all,

 The new parser Parrot supports "implies" operator( => )  now, e.g.

if (itIsRaining => iAmUsingUmbrella) {
  println 'I am dry'
}

   More examples can be found at:
1)
https://github.com/danielsun1106/groovy-parser/blob/impliesOperator/src/test/resources/core/ImpliesOp_01x.groovy
2)
https://github.com/danielsun1106/groovy-parser/blob/impliesOperator/src/test/resources/core/ImpliesOp_02x.groovy
3)
https://github.com/danielsun1106/groovy-parser/blob/impliesOperator/src/test/resources/core/ImpliesOp_03x.groovy

   Any thoughts? If most of us like it, I'll merge the new feature to
parrot branch of apache/groovy and resolve  GROOVY-2576
  

Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/One-more-new-operator-implies-for-Groovy-3-tp5738103.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

答复: About the "implies" operator(GROOVY-2576)

[Daniel Sun]

Hi Cédric,

 Here is the background of the “implies” operator, which is well known in 
the mathematical logic ??
http://mathworld.wolfram.com/Implies.html


发件人: Cédric Champeau [via 
Groovy]<mailto:ml-node+s329449n5738104...@n5.nabble.com>
发送时间: 2017年1月26日 17:12
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: About the "implies" operator(GROOVY-2576)

I'm not convinced we should add more operators. Honestly, I had to read the 
description of the "implies" operator to understand what it does. This is 
clearly not the case for || or &&, which are "well known" operators.

I am also worried about code becoming ascii art:

{ a -> a => a <= c => d }

So I'm just +0, I don't see that I would use it often enough to mitigate the 
drawbacks.

2017-01-26 1:47 GMT+01:00 Daniel Sun <[hidden 
email]>:
Hi Jochen,

  Thanks for your analysis in detail :)

   => is a very expressive operator. if we could implement it as 
+(corresponding to plus method) does and apply different business logic when 
necessary, it would be much more useful. And the default implementation of 
"implies" method can be "!a||b".

As to the association of the operator, I prefer the left association, 
i.e. a => b => c is equivalent to (a => b) => c.

   The above is the initial plan to implement the  "implies" operator.

Cheers,
Daniel.Sun


在 2017年1月26日 上午3:20，"Jochen Theodorou [via Groovy]"  Hi all,
>
>The "implies" operator "=>" was suggested many years ago, here is the
> replated JIRA issue( GROOVY-2576
> <https://issues.apache.org/jira/browse/GROOVY-2576>  ) .
>
>Do you want it for Groovy 3? (+1: yes; -1: no; 0: not bad)
>
>BTW, recently I have been going through the issues related to the old
> parser, many issues existing for many years do not exist in the new parser
> Parrot :)

If we do this (and I say +1) we should clear some things:
1) what does a=>b=>c mean, since (a=>b)=>c is not the same as a=>(b=>c)
2) use groovy truth and when to apply it? If we map a=>b to !a||b, then
it will use Groovy truth on a and b, but if we map to an implies method
it will get a and b, use groovy truth on them or not and we then maybe
use groovy truth on the result. I personally would be for not using
groovy truth here, thus make it more in line with | and &.
3) if a=>b is mapped to !a||b we will evaluate a, negate it, and
depending on the result maybe never evaluate b. As long as a and b are
free of side effects, that does not play an extremely important role,
but if we map it to a method a and b will be evaluated always. If we
would say it is more like !a|b, which would also require both being
evaluated, then there is still the fact that !a ensures we call here
always the boolean or function, never one defined by an arbitrary a
4) instead of using !a, which converts a to a boolean and negates it, we
can also use ~a, which is a binary negate also working on booleans, but
not converting a to a boolean if it is no boolean. Here we have to
especially think about ~a|b calling "or" on a Pattern if a is a String.
Also not many things besides boolean and numbers really support
something useful of the binary negate.

I mention those points so we can make a proper specification for the
behaviour of this operator ;)

bye Jochen



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738042.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


View this message in context: Re: About the "implies" 
operator(GROOVY-2576)<http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738043.html>

Sent from the Groovy Dev mailing list 
archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at 
Nabble.com.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738104.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsd

答复: 答复: About the "implies" operator(GROOVY-2576)

[Daniel Sun]

Hi Guillaume,

  When we deal with logic, abstraction is very important to simplify 
reasoning. The “implies” operator can give us a hand here 😊

Cheers,
Daniel.Sun

发件人: Guillaume Laforge [via 
Groovy]<mailto:ml-node+s329449n5738107...@n5.nabble.com>
发送时间: 2017年1月26日 17:34
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: 答复: About the "implies" operator(GROOVY-2576)

I'm not super convinced either, and I'm wondering when I'd really use such an 
operator.
I'm kinda +0 as Cédric here.

Not that we should copy or not other languages, but are there others that have 
such an operator, and if this is the case, do we know how (much) it's used?

On Thu, Jan 26, 2017 at 10:22 AM, Cédric Champeau <[hidden 
email]> wrote:
I know it's well known in mathematical logic, but I don't want Groovy to become 
Scalaz either. The route is dangerous.

2017-01-26 10:18 GMT+01:00 Daniel Sun <[hidden 
email]>:
Hi Cédric,

 Here is the background of the “implies” operator, which is well known in 
the mathematical logic 😉
http://mathworld.wolfram.com/Implies.html


发件人: [hidden email]<http:///user/SendEmail.jtp?type=node&node=5738105&i=0>
发送时间: 2017年1月26日 17:12
收件人: [hidden email]<http:///user/SendEmail.jtp?type=node&node=5738105&i=1>
主题: Re: About the "implies" operator(GROOVY-2576)

I'm not convinced we should add more operators. Honestly, I had to read the 
description of the "implies" operator to understand what it does. This is 
clearly not the case for || or &&, which are "well known" operators.

I am also worried about code becoming ascii art:

{ a -> a => a <= c => d }

So I'm just +0, I don't see that I would use it often enough to mitigate the 
drawbacks.

2017-01-26 1:47 GMT+01:00 Daniel Sun <[hidden 
email]<http:///user/SendEmail.jtp?type=node&node=5738104&i=0>>:
Hi Jochen,

  Thanks for your analysis in detail :)

   => is a very expressive operator. if we could implement it as 
+(corresponding to plus method) does and apply different business logic when 
necessary, it would be much more useful. And the default implementation of 
"implies" method can be "!a||b".

As to the association of the operator, I prefer the left association, 
i.e. a => b => c is equivalent to (a => b) => c.

   The above is the initial plan to implement the  "implies" operator.

Cheers,
Daniel.Sun


在 2017年1月26日 上午3:20，"Jochen Theodorou [via Groovy]"  Hi all,
>
>The "implies" operator "=>" was suggested many years ago, here is the
> replated JIRA issue( GROOVY-2576
> <https://issues.apache.org/jira/browse/GROOVY-2576>  ) .
>
>Do you want it for Groovy 3? (+1: yes; -1: no; 0: not bad)
>
>BTW, recently I have been going through the issues related to the old
> parser, many issues existing for many years do not exist in the new parser
> Parrot :)

If we do this (and I say +1) we should clear some things:
1) what does a=>b=>c mean, since (a=>b)=>c is not the same as a=>(b=>c)
2) use groovy truth and when to apply it? If we map a=>b to !a||b, then
it will use Groovy truth on a and b, but if we map to an implies method
it will get a and b, use groovy truth on them or not and we then maybe
use groovy truth on the result. I personally would be for not using
groovy truth here, thus make it more in line with | and &.
3) if a=>b is mapped to !a||b we will evaluate a, negate it, and
depending on the result maybe never evaluate b. As long as a and b are
free of side effects, that does not play an extremely important role,
but if we map it to a method a and b will be evaluated always. If we
would say it is more like !a|b, which would also require both being
evaluated, then there is still the fact that !a ensures we call here
always the boolean or function, never one defined by an arbitrary a
4) instead of using !a, which converts a to a boolean and negates it, we
can also use ~a, which is a binary negate also working on booleans, but
not converting a to a boolean if it is no boolean. Here we have to
especially think about ~a|b calling "or" on a Pattern if a is a String.
Also not many things besides boolean and numbers really support
something useful of the binary negate.

I mention those points so we can make a proper specification for the
behaviour of this operator ;)

bye Jochen



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738042.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=insta

答复: One more new operator "implies" ( => ) for Groovy 3

[Daniel Sun]

Hi Jochen,

 => has lower priority than &&, ||, &, |

Cheers,
Daniel.Sun

发件人: Jochen Theodorou [via 
Groovy]<mailto:ml-node+s329449n5738113...@n5.nabble.com>
发送时间: 2017年1月26日 18:42
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: One more new operator "implies" ( => ) for Groovy 3



On 26.01.2017 10:07, Daniel Sun wrote:

> Hi all,
>
>  The new parser Parrot supports "implies" operator( => )  now, e.g.
>
> if (itIsRaining => iAmUsingUmbrella) {
>   println 'I am dry'
> }
>
>More examples can be found at:
> 1)
> https://github.com/danielsun1106/groovy-parser/blob/impliesOperator/src/test/resources/core/ImpliesOp_01x.groovy
> 2)
> https://github.com/danielsun1106/groovy-parser/blob/impliesOperator/src/test/resources/core/ImpliesOp_02x.groovy
> 3)
> https://github.com/danielsun1106/groovy-parser/blob/impliesOperator/src/test/resources/core/ImpliesOp_03x.groovy
>
>Any thoughts? If most of us like it, I'll merge the new feature to
> parrot branch of apache/groovy and resolve  GROOVY-2576
> <https://issues.apache.org/jira/browse/GROOVY-2576>

nice... how is the priority compared to other operators? For example
a=>b&&b=>a, a=>b&b=>a,  a=>b||b=>a, a=>b|b=>a.

bye Jochen



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/One-more-new-operator-implies-for-Groovy-3-tp5738103p5738113.html
To unsubscribe from One more new operator "implies" ( => ) for Groovy 3, click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738103&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODEwM3wxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/One-more-new-operator-implies-for-Groovy-3-tp5738103p5738115.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

答复: 答复: About the "implies" operator(GROOVY-2576)

[Daniel Sun]

Hi Jochen,

 Some like it, some don’t. Understanding the new operator needs some 
knowledge of mathematical logic.

Cheers,
Daniel.Sun

发件人: Jochen Theodorou [via 
Groovy]<mailto:ml-node+s329449n5738114...@n5.nabble.com>
发送时间: 2017年1月26日 18:44
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: 答复: About the "implies" operator(GROOVY-2576)



On 26.01.2017 10:33, Guillaume Laforge wrote:
> I'm not super convinced either, and I'm wondering when I'd really use
> such an operator.

I would and there would have been cases in MetaClassImpl where I would
have used it already, if Java would be able to do such things.

bye Jochen



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738114.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738116.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

答复: 答复: About the "implies" operator(GROOVY-2576)

[Daniel Sun]

Hi Jochen,

 We can enable or disable some rules in the antlr4 grammar, but no rules 
can be defined and enabled on the fly… as you know, the parser is generated by 
antlr4.

Cheers,
Daniel.Sun

发件人: Jochen Theodorou [via 
Groovy]<mailto:ml-node+s329449n5738119...@n5.nabble.com>
发送时间: 2017年1月26日 19:07
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: 答复: About the "implies" operator(GROOVY-2576)



On 26.01.2017 11:13, Andres Almiray wrote:
> Here's another idea:
>
> What if this new operator and other syntax changes were to be introduced
> as parser/compiler plugins?

compiler itself, sure we can do something here... but for the parser?
Daniel, is it possible? I would be surprised if it is, but you never know ;)

> This way the core syntax stays the same yet it may open the possibility
> for certain groups to enhance the Groovy syntax according to their needs
> without affecting everyone else.
>
> Don't how how feasible this is given that it requires changes to both
> parser and compiler APIs.

I have my doubts, since the parser is generated from a grammar

bye Jochen



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738119.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738120.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

答复: About the "implies" operator(GROOVY-2576)

[Daniel Sun]

Hi Jesper,

  As to the custom operator, I have an experimental branch to play with 
it(https://github.com/danielsun1106/groovy-parser/tree/customOperator)😉

  If I’ve caught Jochen’s words, he wants a general approach to extend a 
grammar(not only operator). As far as I know, no approach can deal with it.

  Thanks for your suggestion 😊

Cheers,
Daniel.Sun
发件人: Jesper Steen Møller [via 
Groovy]<mailto:ml-node+s329449n5738122...@n5.nabble.com>
发送时间: 2017年1月26日 19:24
收件人: Daniel Sun<mailto:realblue...@hotmail.com>
主题: Re: About the "implies" operator(GROOVY-2576)

Hi Jochen and Daniel

Not entirely correct: There are some ways to extend a grammar with new 
opperators, as demonstrated in 
http://stackoverflow.com/questions/29894457/dynamic-operator-tokens-in-antlr4
However, this still needs to happen before lexing and parsing, so you can't 
"fix" it with an AST transformer.

-Jesper


On 26 Jan 2017, at 12.20, Daniel Sun <[hidden 
email]> wrote:

Hi Jochen,

 We can enable or disable some rules in the antlr4 grammar, but no rules 
can be defined and enabled on the fly… as you know, the parser is generated by 
antlr4.

Cheers,
Daniel.Sun

发件人: [hidden email]
发送时间: 2017年1月26日 19:07
收件人: [hidden email]
主题: Re: 答复: About the "implies" operator(GROOVY-2576)



On 26.01.2017 11:13, Andres Almiray wrote:
> Here's another idea:
>
> What if this new operator and other syntax changes were to be introduced
> as parser/compiler plugins?

compiler itself, sure we can do something here... but for the parser?
Daniel, is it possible? I would be surprised if it is, but you never know ;)

> This way the core syntax stays the same yet it may open the possibility
> for certain groups to enhance the Groovy syntax according to their needs
> without affecting everyone else.
>
> Don't how how feasible this is given that it requires changes to both
> parser and compiler APIs.

I have my doubts, since the parser is generated from a grammar

bye Jochen



If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738119.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click here.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>


View this message in context: 答复: 答复: About the "implies" 
operator(GROOVY-2576)<http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738120.html>
Sent from the Groovy Dev mailing list 
archive<http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html> at 
Nabble.com<http://Nabble.com>.




If you reply to this email, your message will be added to the discussion below:
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738122.html
To unsubscribe from About the "implies" operator(GROOVY-2576), click 
here<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5738035&code=cmVhbGJsdWVzdW5AaG90bWFpbC5jb218NTczODAzNXwxMTQ2MjE4MjI1>.
NAML<http://groovy.329449.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml>




--
View this message in context: 
http://groovy.329449.n5.nabble.com/About-the-implies-operator-GROOVY-2576-tp5738035p5738123.html
Sent from the Groovy Dev mailing list archive at Nabble.com.

Re: 答复: One more new operator "implies" ( => ) for Groovy 3

[Daniel Sun]

Since 30% of 76 developers don't like the new operator, it will be postponed
to merge into Apache Groovy util most of us like it.

Cheers,
Daniel.Sun




--
View this message in context: 
http://groovy.329449.n5.nabble.com/One-more-new-operator-implies-for-Groovy-3-tp5738103p5738162.html
Sent from the Groovy Dev mailing list archive at Nabble.com.