GROOVY-8527: Enhance import aliasing to an alias with a package name

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
12
Reply | Threaded
Open this post in threaded view
|

GROOVY-8527: Enhance import aliasing to an alias with a package name

Daniel Sun
Hi all,


       Paul proposed to enhance import aliasing to an alias with a package
name(see GROOVY-8527[2]), which I think is useful sometimes, so I have
implemented in groovy-parser project[1].

       If no one rejects it, I will sync it to apache/groovy project.

Cheers,
Daniel.Sun

[1] https://github.com/danielsun1106/groovy-parser/tree/refine-import-as
[2] https://issues.apache.org/jira/browse/GROOVY-8527




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Reply | Threaded
Open this post in threaded view
|

Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

Jochen Theodorou


Am 04.04.2018 um 06:58 schrieb Daniel Sun:

> Hi all,
>
>
>         Paul proposed to enhance import aliasing to an alias with a package
> name(see GROOVY-8527[2]), which I think is useful sometimes, so I have
> implemented in groovy-parser project[1].
>
>         If no one rejects it, I will sync it to apache/groovy project.
>
> Cheers,
> Daniel.Sun
>
> [1] https://github.com/danielsun1106/groovy-parser/tree/refine-import-as
> [2] https://issues.apache.org/jira/browse/GROOVY-8527

I am unclear about the use case for this. I mean if you

import java.lang.String as some.package.MyString

you will have to do "new some.package.MyString()". If you are fully
qualifying the name, why not use the original name instead.

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

Guillaume Laforge
Administrator
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."

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.

Guillaume


On Wed, Apr 4, 2018 at 12:46 PM, Jochen Theodorou <[hidden email]> wrote:


Am 04.04.2018 um 06:58 schrieb Daniel Sun:
Hi all,


        Paul proposed to enhance import aliasing to an alias with a package
name(see GROOVY-8527[2]), which I think is useful sometimes, so I have
implemented in groovy-parser project[1].

        If no one rejects it, I will sync it to apache/groovy project.

Cheers,
Daniel.Sun

[1] https://github.com/danielsun1106/groovy-parser/tree/refine-import-as
[2] https://issues.apache.org/jira/browse/GROOVY-8527

I am unclear about the use case for this. I mean if you

import java.lang.String as some.package.MyString

you will have to do "new some.package.MyString()". If you are fully qualifying the name, why not use the original name instead.

bye Jochen



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Reply | Threaded
Open this post in threaded view
|

Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

Jochen Theodorou


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
MG
Reply | Threaded
Open this post in threaded view
|

Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

MG
In reply to this post by Guillaume Laforge
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" ?

-------- Ursprüngliche Nachricht --------
Von: Guillaume Laforge <[hidden email]>
Datum: 04.04.18 12:55 (GMT+01:00)
Betreff: Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

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

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.

Guillaume


On Wed, Apr 4, 2018 at 12:46 PM, Jochen Theodorou <[hidden email]> wrote:


Am 04.04.2018 um 06:58 schrieb Daniel Sun:
Hi all,


        Paul proposed to enhance import aliasing to an alias with a package
name(see GROOVY-8527[2]), which I think is useful sometimes, so I have
implemented in groovy-parser project[1].

        If no one rejects it, I will sync it to apache/groovy project.

Cheers,
Daniel.Sun

[1] https://github.com/danielsun1106/groovy-parser/tree/refine-import-as
[2] https://issues.apache.org/jira/browse/GROOVY-8527

I am unclear about the use case for this. I mean if you

import java.lang.String as some.package.MyString

you will have to do "new some.package.MyString()". If you are fully qualifying the name, why not use the original name instead.

bye Jochen



--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform

Reply | Threaded
Open this post in threaded view
|

RE: GROOVY-8527: Enhance import aliasing to an alias with a package name

eric.milles
In reply to this post by Guillaume Laforge

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:[hidden email]]
Sent: Wednesday, April 04, 2018 7:32 AM
To: [hidden email]
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" ?

Reply | Threaded
Open this post in threaded view
|

Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

Jochen Theodorou
On 04.04.2018 17:07, [hidden email] wrote:
> [...]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.

not many are eager to spend their spare time after working hours on
fixing complicated bugs and going through the whole process and discussions.

bye Jochen
Reply | Threaded
Open this post in threaded view
|

RE: GROOVY-8527: Enhance import aliasing to an alias with a package name

eric.milles
>> [...]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.
>
> not many are eager to spend their spare time after working hours on fixing complicated bugs and going through the whole process and discussions.

If the incentive for fixing bugs was enticing enough, wouldn't there be eager developers?  What then is the point of adding new features onto an unhealthy, under-supported language?  If this is truly the state of the union, then I would vote NO on all new feature development.
Reply | Threaded
Open this post in threaded view
|

Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

Jochen Theodorou
On 04.04.2018 21:38, [hidden email] wrote:
>>> [...]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.
>>
>> not many are eager to spend their spare time after working hours on fixing complicated bugs and going through the whole process and discussions.
>
> If the incentive for fixing bugs was enticing enough, wouldn't there be eager developers?

Do you have a recipe of how to give an enticing incentive? Actually,
from looking at your issues you are suggesting solutions in some places,
but you seem not be motivated enough to make a pull request for example.
Why is that?

> What then is the point of adding new features onto an unhealthy, under-supported language?

I think you exaggerate. But the point is attracting new people. If you
do not move, people move away. Annoying, long standing bugs can have the
same effect of course

>  If this is truly the state of the union, then I would vote NO on all new feature development.

We need to find the right balance. The new parser for example does not
exist because we wanted a new parser. It exists because the old parser
started to become a problem for fixing bugs. Of course once you have a
new parser, that is more maintainable and a person that understands it
very well, you will also see features from other languages and see them
with the eyes of a parser guy that is wondering if this brings any
benefit to Groovy. That is natural.

Anyway... the static compiler is a deep resource of bugs and will stay
being it a long time. Inner classes in all variants contain new
surprises time over time. But excluding those two topics what are your
top 3 of open bugs in jira entered by you where existing features do not
mix well with eachother or are not completely implemented?

bye Jochen
Reply | Threaded
Open this post in threaded view
|

Re: GROOVY-8527: Enhance import aliasing to an alias with a package name

paulk_asert
In reply to this post by eric.milles
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, <[hidden email]> 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:[hidden email]]
Sent: Wednesday, April 04, 2018 7:32 AM
To: [hidden email]
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" ?


12