If Gradle requires compatibility with the old parser, it seems to me
this is the way to go, unless someone has a very convincing example
showing the new way would actually be better...
Cheers,
mg
On 11/02/2021 11:17, Paul King wrote:
Thanks for the feedback. I have also seen the convention used for
"pseudo" private methods, like you mention. And also for methods named
so as not to conflict with likely names already in source code.
I presume the Gradle codebase has names (or generates names) such as
that (since it triggered this investigation) but it might not be the
only related library/framework using such a convention.
Cheers, Paul.
On Thu, Feb 11, 2021 at 7:58 PM Mario Garcia <mario.g...@gmail.com
<mailto:mario.g...@gmail.com>> wrote:
If it helps, I've seen some programmers with python background
using the underscore in Groovy for method declaration. It seems
they use the convention of the underscore prefix to note these
methods aren't for public consumption.
El jue, 11 feb 2021 a las 9:49, Paul King
(<paul.king.as...@gmail.com <mailto:paul.king.as...@gmail.com>>)
escribió:
Hi folks,
I would be interested in any thoughts about the following issue:
https://issues.apache.org/jira/browse/GROOVY-9936
<https://issues.apache.org/jira/browse/GROOVY-9936>
TL;DR There is an edge case where Groovy 3 (Parrot) behavior
now differs from the old parser. Even though an argument could
be made either way as to which behavior is better, I propose
we align with the old parser.
Proposed PR:
https://github.com/apache/groovy/pull/1485
<https://github.com/apache/groovy/pull/1485>
Let me know your thoughts.
Thanks, 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>
