groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <blackd...@gmx.org>
Subject Re: GROOVY-8527: Enhance import aliasing to an alias with a package name
Date Wed, 04 Apr 2018 12:16:28 GMT


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 retain 
> (perhaps with a commandline switch) the ability to compile source code 
> still using the old package name."

ah, seems I overscrolled that.

> At first, I had the same reaction, as I didn't want to have to type new 
> foo.bar.Baz() instead of new AliasedBaz(), but perhaps it's useful 
> somehow for our split packages trouble.

for me, what is required is something like this:

import x.Y as a.B
import a.B

new B()

then it makes sense. But I don't think that would work, just because the 
grammar is changed. This will imho require more changes

But I wonder if it is worth it. changing some imports is much more 
easily done than if for example the meta class system changes in an 
incompatible way... and I see no way around that currently. We will most 
likely even have to deprecate the remove points for method invocation we 
have since Groovy 1 (ScriptByteCodeAdapter invoke*, get*, set*), and the 
old method caching. The only part, that has a chance of survival is the 
indy version.

bye Jochen

Mime
View raw message