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 solution is important when we "break everything" by moving packages to accommodate JDK9 changes - it is already solved "kind of" that way in Kotlin I believe. But the real fix for that involves several pieces and the grammar change is in reality the least important of these changes and we might find a solution that doesn't even need that change as you say (compiler configuration or whatever). I don't want to focus on doing that right now as I don't think it's the most important thing so I create a Jira so I don't have it keep it in my working memory at all. I can now focus on some important bug fixes. The fact that we have someone else on the team that can work very efficiently in exactly that space is an unusual dynamic of the team at the moment. The team would be healthier with more people looking at some of the bugs but I am not sure totally stopping all innovation leads us down a healthy path either. Anyway, let's get back to the change in question. Given that we don't know the full solution to the source code backward compatibility yet, we should evaluate this change simply on its merits. I suspect not many developers are going to use the import alias feature with fully qualified package names, they will need to type the full name in their code. I can imagine some scenarios where this can prove to be useful but don't see it as super critical. On the other hand, I ask the question "why not" since some users might expect it to work that way and we allow them to do it the hard way, so why not allow them to do it the easy way? I see it as low (but not zero) risk of introducing new errors or interacting with other features. However, for me the red flags would be, can someone use this trick to do something they shouldn't otherwise do, e.g. "create" a class in say the java.lang package or access package protected members by choosing an appropriate package name? These might turn out to be totally irrelevant scenarios but it would be good to investigate a bit more. I am happy for that Jira to sit there until we confirm such matters. I'd also note that this won't impact 2_5_X since it would only be for the new grammar. Cheers, Paul. On Thu, Apr 5, 2018 at 1:07 AM, <eric.mil...@thomsonreuters.com> wrote: > 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 best to me as a user of the language. I must stress again my > sentiment from a couple months ago: there are so many features being added > witout much in the way of discussion that I don't see much focus in what > Groovy 3.0 is intended to be. 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 features. > > > > *From:* mg [mailto:mg...@arscreat.com] > *Sent:* Wednesday, April 04, 2018 7:32 AM > *To:* dev@groovy.apache.org > *Subject:* Re: GROOVY-8527: Enhance import aliasing to an alias with a > package name > > > > 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 used for something like that ?), that could fix or point out > different kinds of "breaking changes spots" ? >
