groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul King <>
Subject Re: GROOVY-8527: Enhance import aliasing to an alias with a package name
Date Thu, 05 Apr 2018 01:27:15 GMT
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, <> 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 []
> *Sent:* Wednesday, April 04, 2018 7:32 AM
> *To:*
> *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" ?

View raw message