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> 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>) > escribió: > >> >> Hi folks, >> >> I would be interested in any thoughts about the following issue: >> >> 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 >> >> 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> >> <#m_8715979887687047295_m_-5064115683895307916_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> >
