groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Sun (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (GROOVY-8527) Enhance import aliasing to an alias with a package name
Date Wed, 04 Apr 2018 03:04:00 GMT

    [ https://issues.apache.org/jira/browse/GROOVY-8527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16424926#comment-16424926
] 

Daniel Sun commented on GROOVY-8527:
------------------------------------

The enhanced grammar will be implemented in Parrot parser

> Enhance import aliasing to an alias with a package name
> -------------------------------------------------------
>
>                 Key: GROOVY-8527
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8527
>             Project: Groovy
>          Issue Type: New Feature
>            Reporter: Paul King
>            Assignee: Daniel Sun
>            Priority: Major
>
> Currently at the syntax level you can do:
> {code:java}
> import java.lang.String as MyString
> {code}
> but the grammar prohibits:
> {code:java}
> import java.lang.String as some.package.MyString
> {code}
> It is already possible to include a dot within the name via the api:
> {code}
> import org.codehaus.groovy.control.CompilerConfiguration
> import org.codehaus.groovy.control.customizers.ImportCustomizer
> def configuration = new CompilerConfiguration()
> def imports = new ImportCustomizer()
> imports.addImport('foo.bar.LegacyDate', 'java.util.Date')
> configuration.addCompilationCustomizers(imports)
> def shell = new GroovyShell(configuration)
> shell.evaluate('println new foo.bar.LegacyDate()')
> {code}
> This usage is not currently common however and perhaps parts of the code base don't expect
it. We should include some further tests and also make sure there aren't any security implications
if someone started using a java.lang.Object alias or something similar.
> We should also consider adding a DEFAULT_ALIASES similar to {{ResolveVisitor#DEFAULT_IMPORTS}}
and consider a mechanism for extending the list (potentially for both).
> 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.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message