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

[Jochen Theodorou]

On 05.04.2018 16:07, eric.mil...@thomsonreuters.com wrote:
[...]

Here are my top 3 from my bugs list:
GROOVY-8509 error for call to protected method from same package
GROOVY-8063 Type annotation value referencing inner class is not properly scoped


oh,I said no static compilation and no inner classes ;)


GROOVY-7975 Use of static final field in an annotation element causes compile 
errors


now this one has even a good looking patch suggestion and is neither 
static compilation nor inner classes related


bye Jochen

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

[eric.milles]

Yes, the statements I made are a bit exaggerated.  That was to bring out a 
little more discussion on balance of maintenance vs enhancement.

In my case, I am suggesting fixes because I have groovy-eclipse setup and this 
gives me a chance to make some small patches to groovy-core and see if they fix 
the problems I run into.  For me to submit a PR to groovy-core, I would need to 
get that entire project setup and get familiarized with the build and test 
cycle.  And then how would I decide how much time to spend trying to improve 
groovy-eclipse vs. groovy-core.  I felt that reporting issues and submitting 
diffs/patches would be sufficient.


Here are my top 3 from my bugs list:
GROOVY-8509 error for call to protected method from same package
GROOVY-8063 Type annotation value referencing inner class is not properly scoped
GROOVY-7975 Use of static final field in an annotation element causes compile 
errors

-Original Message-
From: Jochen Theodorou [mailto:blackd...@gmx.org] 
Sent: Wednesday, April 04, 2018 7:37 PM
To: dev@groovy.apache.org
Subject: Re: GROOVY-8527: Enhance import aliasing to an alias with a package 
name

On 04.04.2018 21:38, eric.mil...@thomsonreuters.com 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

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

[Daniel.Sun]

Hi Eric,

  Groovy language must evolve to survive. 
  How to evolve? 1) Adding useful new features; 2) Fixing existing bugs;

  As for 1), the old parser has not been maintained for a long time, new
features are hard to implement, so I spent several months to develop the
brand new parser Parrot(700+ commits to groovy-parser project util now). Not
only make it compatible with existing grammar, but also handle most of
Java7+ grammar properly. Though my effort is vetoed by someone, I love
Groovy, so I still continue contributing without any payment and flower.

  As for 2), I always try to fix some critical even blocker bugs. e.g.
GROOVY-8439, do you know how long I spend to fix it? whole night... In
someone's option, groovy core team does not fix bugs eagerly, they are wrong
in fact. Some bugs are really hard to fix especially STC related.

  At last, thanks for your effort on reporting bugs and developing the
appealing eclipse plugin for Groovy!

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

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

[Paul King]

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

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

[Jochen Theodorou]

On 04.04.2018 21:38, eric.mil...@thomsonreuters.com 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

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.

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

[Jochen Theodorou]

On 04.04.2018 17:07, eric.mil...@thomsonreuters.com 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

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

[eric.milles]

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

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

[mg]

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 
 Datum: 04.04.18  12:55  (GMT+01:00) An: 
dev@groovy.apache.org 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  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-PresidentDeveloper Advocate @ Google Cloud 
Platform

Blog: http://glaforge.appspot.com/Social: @glaforge / Google+

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

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

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

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

Blog: http://glaforge.appspot.com/
Social: @glaforge  / Google+

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