On 05.04.2018 16:07, eric.mil...@thomsonreuters.com wrote:
[...]
Here are my top 3 from my bugs list:
GROOVY-8509 error for call to protected method from same package
GROOVY-8063 Type annotation value referencing inner class is not properly scoped
oh,I said no static compilation and no inner
Yes, the statements I made are a bit exaggerated. That was to bring out a
little more discussion on balance of maintenance vs enhancement.
In my case, I am suggesting fixes because I have groovy-eclipse setup and this
gives me a chance to make some small patches to groovy-core and see if they
Hi Eric,
Groovy language must evolve to survive.
How to evolve? 1) Adding useful new features; 2) Fixing existing bugs;
As for 1), the old parser has not been maintained for a long time, new
features are hard to implement, so I spent several months to develop the
brand new
Hi Eric,
I am super keen to get long standing bugs fixed - just many of them are
quite difficult to fix without breaking other things. But we should just
keep putting significant emphasis on fixing them anyway.
Wrt the "enhanced" import aliasing. I think providing a backward source
compatibility
On 04.04.2018 21:38, eric.mil...@thomsonreuters.com wrote:
[...]I have submitted over 20 bugs in
the past months for existing features that do not mix well with
eachother or are not completely implemented and yet I feel the core
development thrust is not in fixing bugs for existing features but
>> [...]I have submitted over 20 bugs in
>> the past months for existing features that do not mix well with
>> eachother or are not completely implemented and yet I feel the core
>> development thrust is not in fixing bugs for existing features but in
>> adding new features for the sake of new
On 04.04.2018 17:07, eric.mil...@thomsonreuters.com wrote:
[...]I have submitted over 20 bugs in
the past months for existing features that do not mix well with
eachother or are not completely implemented and yet I feel the core
development thrust is not in fixing bugs for existing features
I agree; I don't see the value here. Could the backwards compat problem be
solved with compiler configuration (aka a global transform)?
I have heard from many developers that import aliasing is a feature they don't
particularly like. Adding an odd edge case to this feature seems confusing at
Hmmm - is it really worth introducing this feature for a temporary backward
compatibility fix, especially considering Paul himself is mentioning some
security concerns ? Wouldn't it be better to supply e.g. a small tool that
converts Groovy pre-module-code to Groovy 3.0 code (could CodeNarc be
Am 04.04.2018 um 12:55 schrieb Guillaume Laforge:
See Paul's description in the JIRA issue for the motivation:
"My use case is around JDK9+ modules. We might move the package for,
e.g. groovy.util.XmlSlurper to something like
groovy.xml.parsers.XmlSlurper (or whatever) but we might like to
See Paul's description in the JIRA issue for the motivation:
"My use case is around JDK9+ modules. We might move the package for, e.g.
groovy.util.XmlSlurper to something like groovy.xml.parsers.XmlSlurper (or
whatever) but we might like to retain (perhaps with a commandline switch)
the ability
Am 04.04.2018 um 06:58 schrieb Daniel Sun:
Hi all,
Paul proposed to enhance import aliasing to an alias with a package
name(see GROOVY-8527[2]), which I think is useful sometimes, so I have
implemented in groovy-parser project[1].
If no one rejects it, I will sync it to
12 matches
Mail list logo
