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