You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by "Daniel.Sun" <su...@apache.org> on 2018/05/04 01:38:34 UTC
[VOTE] Support Java-like array
Dear development community,
In order to improve Groovy's compatibility with Java(Copy & Paste) and
make Groovy more friendly to Java developers[1], I propose to support
Java-like array[2][3] and start the VOTE thread for supporting Java-like
array.
Please vote on supporting Java-like array since Apache Groovy 3.0.0.
Here are the poll results from twitter and user mailing list for your
reference:
Sum up the poll results
24 votes in total(including my +1)
15 +1 (62.5%)
9 0 (37.5%)
0 -1 ( 0.0%)
Twitter[4]
19 votes in total(not including my +1)
58% +1,
42% 0,
0% -1
User mailing list(
http://groovy.329449.n5.nabble.com/Poll-About-supporting-Java-like-array-tt5749923.html
)
4 votes in total(not including my +1)
3 +1,
1 0,
0 -1
The vote is open for the next 72 hours and passes if a majority of at least
three +1 PMC votes are cast.
[ ] +1 Support Java-like array
[ ] 0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not support Java-like array because...
Here is my vote:
+1
Cheers,
Daniel.Sun
[1] http://groovy-lang.org/differences.html
[2] https://github.com/apache/groovy/pull/691
[3] https://issues.apache.org/jira/browse/GROOVY-8561
[4] https://twitter.com/daniel_sun/status/990544485196091395
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Paul,
I've added your proposed provisos to the PR. Thanks for your voting.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by Paul King <pa...@asert.com.au>.
+1 with the following provisos:
* we need to update the breaking changes section of 3.0.0 release notes on
the website (site/src/site/releasenotes/groovy-3.0.adoc) to include the
cases listed in GROOVY-8561
* we need to update the "Array initializers" section of
core-differences-java.adoc (we need to explain what cases remain -
obviously if no array type is specified is one case - I haven't checked
whether Java allows arrays of lambdas or something similar which we may not
support - I don't believe so but haven't researched into it)
* we need to update the "Arrays" section of core-syntax.adoc (I think we
need to indicate that square brackets is the idiomatic approach and also
explicitly say that closure is the default interpretation of curly braces
unless the array target type can be inferred from the context.)
I think it is probably worth adding the last two into the PR for any future
reviewers. We should also update the "Lists" section of core-syntax.adoc to
include information about Groovy's auto promotion of a single item into an
array. I guess that isn't really part of this change but since that is
where the breaking changes changes will be for the degenerate edge cases, I
think we had better make that clearer.
I am happy to help with the wording in the doco changes (time permitting).
Cheers, Paul.
On Fri, May 4, 2018 at 11:38 AM, Daniel.Sun <su...@apache.org> wrote:
> Dear development community,
>
> In order to improve Groovy's compatibility with Java(Copy & Paste) and
> make Groovy more friendly to Java developers[1], I propose to support
> Java-like array[2][3] and start the VOTE thread for supporting Java-like
> array.
>
> Please vote on supporting Java-like array since Apache Groovy 3.0.0.
>
> Here are the poll results from twitter and user mailing list for your
> reference:
>
> Sum up the poll results
> 24 votes in total(including my +1)
> 15 +1 (62.5%)
> 9 0 (37.5%)
> 0 -1 ( 0.0%)
>
> Twitter[4]
> 19 votes in total(not including my +1)
> 58% +1,
> 42% 0,
> 0% -1
>
> User mailing list(
> http://groovy.329449.n5.nabble.com/Poll-About-supporting-Java-like-array-
> tt5749923.html
> )
> 4 votes in total(not including my +1)
> 3 +1,
> 1 0,
> 0 -1
>
> The vote is open for the next 72 hours and passes if a majority of at least
> three +1 PMC votes are cast.
>
> [ ] +1 Support Java-like array
> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not support Java-like array because...
>
> Here is my vote:
>
> +1
>
> Cheers,
> Daniel.Sun
> [1] http://groovy-lang.org/differences.html
> [2] https://github.com/apache/groovy/pull/691
> [3] https://issues.apache.org/jira/browse/GROOVY-8561
> [4] https://twitter.com/daniel_sun/status/990544485196091395
>
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: [VOTE] Support Java-like array
Posted by Paul King <pa...@asert.com.au>.
Yes, three +1 PMC votes is probably overkill for anything but the biggest
changes but we've always had that implication in mind when using [VOTE].
So, in hindsight, this email should have been a [VOTE][LAZY]. I was about
to explain that subtlety to Daniel in my attempts to mentor/pass on the
Apache way but he was very productive and got the vote email out before I
got the chance.
Perhaps one of the PMC members will change their mind or after some time,
additional changes in Java might make this change more important again.
Yes, we should clarify "qualified voter".
Cheers, Paul.
On Sun, May 13, 2018 at 9:49 PM, Remko Popma <re...@gmail.com> wrote:
> For code change votes, since a single -1 veto is sufficient to prevent the
> change from going in, it may be a bit overkill to also require three
> _binding_ (PMC) votes. Whether the veto vote needs to be a binding vote
> from a PMC member or not is (deliberately?) vague in [1]. The document
> mentions a “qualified voter”. I guess each community should figure out what
> that means exactly for them.
>
> Otherwise, it is probably good to formalize the guideline that committers
> should create PRs for potentially contentious code changes.
>
> [1]
> https://www.apache.org/foundation/voting.html
>
> Remko
>
> On Sun, May 13, 2018 at 17:57 Paul King <pa...@asert.com.au> wrote:
>
>> My understanding is that there is some flexibility when asking for votes
>> so long as it is clear up front what the expectation is, see e.g. [1]. Even
>> though there are numerous generic Apache sites with similar descriptions, I
>> was thinking of adding some more content in some of our pages to summarise
>> the most relevant information for our project. I was thinking of some
>> additional wording to the "Contributing code" section of the website to
>> indicate that typically committers should be following the same guidelines
>> (creating PRs etc.) for any significant code change as for people without
>> committer status. Also, I was going to add some wording somewhere around
>> our typical conventions for voting. Something like:
>>
>> We strongly value keeping consensus within the project. Sometimes
>> consensus is obvious from general discussions or informal +1s in PRs or
>> Jira issues. For significant changes within PRs or Jiras, it is good to
>> send an informational to the dev mailing list in any case. When consensus
>> is not obvious or for potentially contentious changes, emails with a [VOTE]
>> in the subject line are a good way to ascertain consensus. Typical
>> scenarios are:
>> * [VOTE] for a release - requires 3 more binding +1 votes than -1 votes
>> (no veto capability)
>> * [VOTE] for code change - requires 3 binding +1s but can be vetoed with
>> a single -1 binding vote
>> * [VOTE][LAZY] for code change - assumes absence of a vote is a +1 (but
>> you'd normally want at least one binding +1 so best to wait a bit longer if
>> you don't have at least one) but can be vetoed with a single -1 binding vote
>> A committer creating a PR request is similar to [VOTE][LAZY].
>> 72 hours is the minimum for such votes but there is no maximum time delay
>> - though waiting too long isn't a good idea since the circumstances which
>> lead to earlier +1s might have changed.
>>
>> If anyone has improvements for this wording, let me know.
>>
>> [1] https://www.apache.org/foundation/voting.html
>>
>> Cheers, Paul.
>>
>> On Sun, May 13, 2018 at 2:20 PM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> That’s probably why over at Log4j we use slightly different language for
>>> voting:
>>>
>>> “The vote will remain open for 72 hours (or more if required). At least
>>> 3 +1 votes ...”
>>>
>>> It seems unfair that by not participating, it is possible to essentially
>>> vote -0 or -1 without justification...
>>>
>>> Thoughts?
>>>
>>> Remko
>>>
>>> > On May 13, 2018, at 11:48, Daniel.Sun <su...@apache.org> wrote:
>>> >
>>> > Please see my original email:
>>> > "The vote is open for the next 72 hours and passes if a majority of at
>>> least
>>> > three +1 PMC votes are cast."
>>> >
>>> > Cheers,
>>> > Daniel.Sun
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>>
Re: [VOTE] Support Java-like array
Posted by Remko Popma <re...@gmail.com>.
For code change votes, since a single -1 veto is sufficient to prevent the
change from going in, it may be a bit overkill to also require three
_binding_ (PMC) votes. Whether the veto vote needs to be a binding vote
from a PMC member or not is (deliberately?) vague in [1]. The document
mentions a “qualified voter”. I guess each community should figure out what
that means exactly for them.
Otherwise, it is probably good to formalize the guideline that committers
should create PRs for potentially contentious code changes.
[1]
https://www.apache.org/foundation/voting.html
Remko
On Sun, May 13, 2018 at 17:57 Paul King <pa...@asert.com.au> wrote:
> My understanding is that there is some flexibility when asking for votes
> so long as it is clear up front what the expectation is, see e.g. [1]. Even
> though there are numerous generic Apache sites with similar descriptions, I
> was thinking of adding some more content in some of our pages to summarise
> the most relevant information for our project. I was thinking of some
> additional wording to the "Contributing code" section of the website to
> indicate that typically committers should be following the same guidelines
> (creating PRs etc.) for any significant code change as for people without
> committer status. Also, I was going to add some wording somewhere around
> our typical conventions for voting. Something like:
>
> We strongly value keeping consensus within the project. Sometimes
> consensus is obvious from general discussions or informal +1s in PRs or
> Jira issues. For significant changes within PRs or Jiras, it is good to
> send an informational to the dev mailing list in any case. When consensus
> is not obvious or for potentially contentious changes, emails with a [VOTE]
> in the subject line are a good way to ascertain consensus. Typical
> scenarios are:
> * [VOTE] for a release - requires 3 more binding +1 votes than -1 votes
> (no veto capability)
> * [VOTE] for code change - requires 3 binding +1s but can be vetoed with a
> single -1 binding vote
> * [VOTE][LAZY] for code change - assumes absence of a vote is a +1 (but
> you'd normally want at least one binding +1 so best to wait a bit longer if
> you don't have at least one) but can be vetoed with a single -1 binding vote
> A committer creating a PR request is similar to [VOTE][LAZY].
> 72 hours is the minimum for such votes but there is no maximum time delay
> - though waiting too long isn't a good idea since the circumstances which
> lead to earlier +1s might have changed.
>
> If anyone has improvements for this wording, let me know.
>
> [1] https://www.apache.org/foundation/voting.html
>
> Cheers, Paul.
>
> On Sun, May 13, 2018 at 2:20 PM, Remko Popma <re...@gmail.com>
> wrote:
>
>> That’s probably why over at Log4j we use slightly different language for
>> voting:
>>
>> “The vote will remain open for 72 hours (or more if required). At least 3
>> +1 votes ...”
>>
>> It seems unfair that by not participating, it is possible to essentially
>> vote -0 or -1 without justification...
>>
>> Thoughts?
>>
>> Remko
>>
>> > On May 13, 2018, at 11:48, Daniel.Sun <su...@apache.org> wrote:
>> >
>> > Please see my original email:
>> > "The vote is open for the next 72 hours and passes if a majority of at
>> least
>> > three +1 PMC votes are cast."
>> >
>> > Cheers,
>> > Daniel.Sun
>> >
>> >
>> >
>> >
>> > --
>> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>
Re: [VOTE] Support Java-like array
Posted by Cédric Champeau <ce...@gmail.com>.
I think it would be good to extend the vote, yes, or re-vote, it's not a
problem.
2018-05-15 8:34 GMT+02:00 Remko Popma <re...@gmail.com>:
> Cédric,
>
> Should the voting period be extended for this vote?
>
> Remko
>
>
>
> On May 15, 2018, at 15:07, Cédric Champeau <ce...@gmail.com>
> wrote:
>
> I can say why I didn't vote: I didn't have time to review the proposal and
> its consequences, so I don't want to give a blind +1 or -1.
>
> Le mar. 15 mai 2018 à 08:03, mg <mg...@arscreat.com> a écrit :
>
>> What I meant to say yesterday at 1am was: "On the other hand I do not get
>> why only 2 PMC members have been voting +1 on this proposal..."
>>
>> This is not against voting +0, but about why so few PMC members vote at
>> all... (?)
>>
>> -------- Ursprüngliche Nachricht --------
>> Von: MG <mg...@arscreat.com>
>> Datum: 15.05.18 00:57 (GMT+01:00)
>> An: dev@groovy.apache.org, Paul King <pa...@asert.com.au>
>> Betreff: Re: [VOTE] Support Java-like array
>>
>> My 10 cents:
>> [VOTE][LAZY] seems a bit odd - if PMC members are on vacation/ill/afk one
>> person could basically push through sweeping changes, which seems odd.
>> On the other had I do not get why only 2 PMC members have been voting on
>> this proposal - if you do not care either way, and it already has 2 x +1,
>> just push it over the edge, if you are really against it, shoot it down
>> with -1...
>> Cheers,
>> mg
>>
>>
>> On 13.05.2018 10:57, Paul King wrote:
>>
>> My understanding is that there is some flexibility when asking for votes
>> so long as it is clear up front what the expectation is, see e.g. [1]. Even
>> though there are numerous generic Apache sites with similar descriptions, I
>> was thinking of adding some more content in some of our pages to summarise
>> the most relevant information for our project. I was thinking of some
>> additional wording to the "Contributing code" section of the website to
>> indicate that typically committers should be following the same guidelines
>> (creating PRs etc.) for any significant code change as for people without
>> committer status. Also, I was going to add some wording somewhere around
>> our typical conventions for voting. Something like:
>>
>> We strongly value keeping consensus within the project. Sometimes
>> consensus is obvious from general discussions or informal +1s in PRs or
>> Jira issues. For significant changes within PRs or Jiras, it is good to
>> send an informational to the dev mailing list in any case. When consensus
>> is not obvious or for potentially contentious changes, emails with a [VOTE]
>> in the subject line are a good way to ascertain consensus. Typical
>> scenarios are:
>> * [VOTE] for a release - requires 3 more binding +1 votes than -1 votes
>> (no veto capability)
>> * [VOTE] for code change - requires 3 binding +1s but can be vetoed with
>> a single -1 binding vote
>> * [VOTE][LAZY] for code change - assumes absence of a vote is a +1 (but
>> you'd normally want at least one binding +1 so best to wait a bit longer if
>> you don't have at least one) but can be vetoed with a single -1 binding vote
>> A committer creating a PR request is similar to [VOTE][LAZY].
>> 72 hours is the minimum for such votes but there is no maximum time delay
>> - though waiting too long isn't a good idea since the circumstances which
>> lead to earlier +1s might have changed.
>>
>> If anyone has improvements for this wording, let me know.
>>
>> [1] https://www.apache.org/foundation/voting.html
>>
>> Cheers, Paul.
>>
>> On Sun, May 13, 2018 at 2:20 PM, Remko Popma <re...@gmail.com>
>> wrote:
>>
>>> That’s probably why over at Log4j we use slightly different language for
>>> voting:
>>>
>>> “The vote will remain open for 72 hours (or more if required). At least
>>> 3 +1 votes ...”
>>>
>>> It seems unfair that by not participating, it is possible to essentially
>>> vote -0 or -1 without justification...
>>>
>>> Thoughts?
>>>
>>> Remko
>>>
>>> > On May 13, 2018, at 11:48, Daniel.Sun <su...@apache.org> wrote:
>>> >
>>> > Please see my original email:
>>> > "The vote is open for the next 72 hours and passes if a majority of at
>>> least
>>> > three +1 PMC votes are cast."
>>> >
>>> > Cheers,
>>> > Daniel.Sun
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>>
>>
Re: [VOTE] Support Java-like array
Posted by Remko Popma <re...@gmail.com>.
Cédric,
Should the voting period be extended for this vote?
Remko
> On May 15, 2018, at 15:07, Cédric Champeau <ce...@gmail.com> wrote:
>
> I can say why I didn't vote: I didn't have time to review the proposal and its consequences, so I don't want to give a blind +1 or -1.
>
>> Le mar. 15 mai 2018 à 08:03, mg <mg...@arscreat.com> a écrit :
>> What I meant to say yesterday at 1am was: "On the other hand I do not get why only 2 PMC members have been voting +1 on this proposal..."
>>
>> This is not against voting +0, but about why so few PMC members vote at all... (?)
>>
>> -------- Ursprüngliche Nachricht --------
>> Von: MG <mg...@arscreat.com>
>> Datum: 15.05.18 00:57 (GMT+01:00)
>> An: dev@groovy.apache.org, Paul King <pa...@asert.com.au>
>> Betreff: Re: [VOTE] Support Java-like array
>>
>> My 10 cents:
>> [VOTE][LAZY] seems a bit odd - if PMC members are on vacation/ill/afk one person could basically push through sweeping changes, which seems odd.
>> On the other had I do not get why only 2 PMC members have been voting on this proposal - if you do not care either way, and it already has 2 x +1, just push it over the edge, if you are really against it, shoot it down with -1...
>> Cheers,
>> mg
>>
>>
>>> On 13.05.2018 10:57, Paul King wrote:
>>> My understanding is that there is some flexibility when asking for votes so long as it is clear up front what the expectation is, see e.g. [1]. Even though there are numerous generic Apache sites with similar descriptions, I was thinking of adding some more content in some of our pages to summarise the most relevant information for our project. I was thinking of some additional wording to the "Contributing code" section of the website to indicate that typically committers should be following the same guidelines (creating PRs etc.) for any significant code change as for people without committer status. Also, I was going to add some wording somewhere around our typical conventions for voting. Something like:
>>>
>>> We strongly value keeping consensus within the project. Sometimes consensus is obvious from general discussions or informal +1s in PRs or Jira issues. For significant changes within PRs or Jiras, it is good to send an informational to the dev mailing list in any case. When consensus is not obvious or for potentially contentious changes, emails with a [VOTE] in the subject line are a good way to ascertain consensus. Typical scenarios are:
>>> * [VOTE] for a release - requires 3 more binding +1 votes than -1 votes (no veto capability)
>>> * [VOTE] for code change - requires 3 binding +1s but can be vetoed with a single -1 binding vote
>>> * [VOTE][LAZY] for code change - assumes absence of a vote is a +1 (but you'd normally want at least one binding +1 so best to wait a bit longer if you don't have at least one) but can be vetoed with a single -1 binding vote
>>> A committer creating a PR request is similar to [VOTE][LAZY].
>>> 72 hours is the minimum for such votes but there is no maximum time delay - though waiting too long isn't a good idea since the circumstances which lead to earlier +1s might have changed.
>>>
>>> If anyone has improvements for this wording, let me know.
>>>
>>> [1] https://www.apache.org/foundation/voting.html
>>>
>>> Cheers, Paul.
>>>
>>> On Sun, May 13, 2018 at 2:20 PM, Remko Popma <re...@gmail.com> wrote:
>>>> That’s probably why over at Log4j we use slightly different language for voting:
>>>>
>>>> “The vote will remain open for 72 hours (or more if required). At least 3 +1 votes ...”
>>>>
>>>> It seems unfair that by not participating, it is possible to essentially vote -0 or -1 without justification...
>>>>
>>>> Thoughts?
>>>>
>>>> Remko
>>>>
>>>> > On May 13, 2018, at 11:48, Daniel.Sun <su...@apache.org> wrote:
>>>> >
>>>> > Please see my original email:
>>>> > "The vote is open for the next 72 hours and passes if a majority of at least
>>>> > three +1 PMC votes are cast."
>>>> >
>>>> > Cheers,
>>>> > Daniel.Sun
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
Re: [VOTE] Support Java-like array
Posted by Cédric Champeau <ce...@gmail.com>.
I can say why I didn't vote: I didn't have time to review the proposal and
its consequences, so I don't want to give a blind +1 or -1.
Le mar. 15 mai 2018 à 08:03, mg <mg...@arscreat.com> a écrit :
> What I meant to say yesterday at 1am was: "On the other hand I do not get
> why only 2 PMC members have been voting +1 on this proposal..."
>
> This is not against voting +0, but about why so few PMC members vote at
> all... (?)
>
> -------- Ursprüngliche Nachricht --------
> Von: MG <mg...@arscreat.com>
> Datum: 15.05.18 00:57 (GMT+01:00)
> An: dev@groovy.apache.org, Paul King <pa...@asert.com.au>
> Betreff: Re: [VOTE] Support Java-like array
>
> My 10 cents:
> [VOTE][LAZY] seems a bit odd - if PMC members are on vacation/ill/afk one
> person could basically push through sweeping changes, which seems odd.
> On the other had I do not get why only 2 PMC members have been voting on
> this proposal - if you do not care either way, and it already has 2 x +1,
> just push it over the edge, if you are really against it, shoot it down
> with -1...
> Cheers,
> mg
>
>
> On 13.05.2018 10:57, Paul King wrote:
>
> My understanding is that there is some flexibility when asking for votes
> so long as it is clear up front what the expectation is, see e.g. [1]. Even
> though there are numerous generic Apache sites with similar descriptions, I
> was thinking of adding some more content in some of our pages to summarise
> the most relevant information for our project. I was thinking of some
> additional wording to the "Contributing code" section of the website to
> indicate that typically committers should be following the same guidelines
> (creating PRs etc.) for any significant code change as for people without
> committer status. Also, I was going to add some wording somewhere around
> our typical conventions for voting. Something like:
>
> We strongly value keeping consensus within the project. Sometimes
> consensus is obvious from general discussions or informal +1s in PRs or
> Jira issues. For significant changes within PRs or Jiras, it is good to
> send an informational to the dev mailing list in any case. When consensus
> is not obvious or for potentially contentious changes, emails with a [VOTE]
> in the subject line are a good way to ascertain consensus. Typical
> scenarios are:
> * [VOTE] for a release - requires 3 more binding +1 votes than -1 votes
> (no veto capability)
> * [VOTE] for code change - requires 3 binding +1s but can be vetoed with a
> single -1 binding vote
> * [VOTE][LAZY] for code change - assumes absence of a vote is a +1 (but
> you'd normally want at least one binding +1 so best to wait a bit longer if
> you don't have at least one) but can be vetoed with a single -1 binding vote
> A committer creating a PR request is similar to [VOTE][LAZY].
> 72 hours is the minimum for such votes but there is no maximum time delay
> - though waiting too long isn't a good idea since the circumstances which
> lead to earlier +1s might have changed.
>
> If anyone has improvements for this wording, let me know.
>
> [1] https://www.apache.org/foundation/voting.html
>
> Cheers, Paul.
>
> On Sun, May 13, 2018 at 2:20 PM, Remko Popma <re...@gmail.com>
> wrote:
>
>> That’s probably why over at Log4j we use slightly different language for
>> voting:
>>
>> “The vote will remain open for 72 hours (or more if required). At least 3
>> +1 votes ...”
>>
>> It seems unfair that by not participating, it is possible to essentially
>> vote -0 or -1 without justification...
>>
>> Thoughts?
>>
>> Remko
>>
>> > On May 13, 2018, at 11:48, Daniel.Sun <su...@apache.org> wrote:
>> >
>> > Please see my original email:
>> > "The vote is open for the next 72 hours and passes if a majority of at
>> least
>> > three +1 PMC votes are cast."
>> >
>> > Cheers,
>> > Daniel.Sun
>> >
>> >
>> >
>> >
>> > --
>> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>
>
Re: [VOTE] Support Java-like array
Posted by mg <mg...@arscreat.com>.
What I meant to say yesterday at 1am was: "On the other hand I do not get why only 2 PMC members have been
voting +1 on this proposal..."
This is not against voting +0, but about why so few PMC members vote at all... (?)
-------- Ursprüngliche Nachricht --------Von: MG <mg...@arscreat.com> Datum: 15.05.18 00:57 (GMT+01:00) An: dev@groovy.apache.org, Paul King <pa...@asert.com.au> Betreff: Re: [VOTE] Support Java-like array
My 10 cents:
[VOTE][LAZY] seems a bit odd - if PMC members are on
vacation/ill/afk one person could basically push through sweeping
changes, which seems odd.
On the other had I do not get why only 2 PMC members have been
voting on this proposal - if you do not care either way, and it
already has 2 x +1, just push it over the edge, if you are really
against it, shoot it down with -1...
Cheers,
mg
On 13.05.2018 10:57, Paul King wrote:
My understanding is that there is some flexibility
when asking for votes so long as it is clear up front what the
expectation is, see e.g. [1]. Even though there are numerous
generic Apache sites with similar descriptions, I was thinking
of adding some more content in some of our pages to summarise
the most relevant information for our project. I was thinking of
some additional wording to the "Contributing code" section of
the website to indicate that typically committers should be
following the same guidelines (creating PRs etc.) for any
significant code change as for people without committer status.
Also, I was going to add some wording somewhere around our
typical conventions for voting. Something like:
We strongly value keeping consensus within the
project. Sometimes consensus is obvious from general
discussions or informal +1s in PRs or Jira issues. For
significant changes within PRs or Jiras, it is good to
send an informational to the dev mailing list in any
case. When consensus is not obvious or for potentially
contentious changes, emails with a [VOTE] in the subject
line are a good way to ascertain consensus. Typical
scenarios are:
* [VOTE] for a release - requires 3 more binding +1
votes than -1 votes (no veto capability)
* [VOTE] for code change - requires 3 binding +1s
but can be vetoed with a single -1 binding vote
*
[VOTE][LAZY] for code change - assumes absence of
a vote is a +1 (but you'd normally want at least
one binding +1 so best to wait a bit longer if you
don't have at least one) but can be vetoed with a
single -1 binding vote
A committer creating a PR request is similar to
[VOTE][LAZY].
72
hours is the minimum for such votes but there is
no maximum time delay - though waiting too long
isn't a good idea since the circumstances which
lead to earlier +1s might have changed.
If anyone has improvements for this wording, let
me know.
[1] https://www.apache.org/foundation/voting.html
Cheers, Paul.
On Sun, May 13, 2018 at 2:20 PM, Remko
Popma <re...@gmail.com>
wrote:
That’s
probably why over at Log4j we use slightly different
language for voting:
“The vote will remain open for 72 hours (or more if
required). At least 3 +1 votes ...”
It seems unfair that by not participating, it is possible to
essentially vote -0 or -1 without justification...
Thoughts?
Remko
> On May 13, 2018, at 11:48, Daniel.Sun <su...@apache.org>
wrote:
>
> Please see my original email:
> "The vote is open for the next 72 hours and passes
if a majority of at least
> three +1 PMC votes are cast."
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by MG <mg...@arscreat.com>.
My 10 cents:
[VOTE][LAZY] seems a bit odd - if PMC members are on vacation/ill/afk
one person could basically push through sweeping changes, which seems odd.
On the other had I do not get why only 2 PMC members have been voting on
this proposal - if you do not care either way, and it already has 2 x
+1, just push it over the edge, if you are really against it, shoot it
down with -1...
Cheers,
mg
On 13.05.2018 10:57, Paul King wrote:
> My understanding is that there is some flexibility when asking for
> votes so long as it is clear up front what the expectation is, see
> e.g. [1]. Even though there are numerous generic Apache sites with
> similar descriptions, I was thinking of adding some more content in
> some of our pages to summarise the most relevant information for our
> project. I was thinking of some additional wording to the
> "Contributing code" section of the website to indicate that typically
> committers should be following the same guidelines (creating PRs etc.)
> for any significant code change as for people without committer
> status. Also, I was going to add some wording somewhere around our
> typical conventions for voting. Something like:
>
> We strongly value keeping consensus within the project. Sometimes
> consensus is obvious from general discussions or informal +1s in PRs
> or Jira issues. For significant changes within PRs or Jiras, it is
> good to send an informational to the dev mailing list in any case.
> When consensus is not obvious or for potentially contentious changes,
> emails with a [VOTE] in the subject line are a good way to ascertain
> consensus. Typical scenarios are:
> * [VOTE] for a release - requires 3 more binding +1 votes than -1
> votes (no veto capability)
> * [VOTE] for code change - requires 3 binding +1s but can be vetoed
> with a single -1 binding vote
> * [VOTE][LAZY] for code change - assumes absence of a vote is a +1
> (but you'd normally want at least one binding +1 so best to wait a bit
> longer if you don't have at least one) but can be vetoed with a single
> -1 binding vote
> A committer creating a PR request is similar to [VOTE][LAZY].
> 72 hours is the minimum for such votes but there is no maximum time
> delay - though waiting too long isn't a good idea since the
> circumstances which lead to earlier +1s might have changed.
>
> If anyone has improvements for this wording, let me know.
>
> [1] https://www.apache.org/foundation/voting.html
> <https://www.apache.org/foundation/voting.html>
>
> Cheers, Paul.
>
> On Sun, May 13, 2018 at 2:20 PM, Remko Popma <remko.popma@gmail.com
> <ma...@gmail.com>> wrote:
>
> That’s probably why over at Log4j we use slightly different
> language for voting:
>
> “The vote will remain open for 72 hours (or more if required). At
> least 3 +1 votes ...”
>
> It seems unfair that by not participating, it is possible to
> essentially vote -0 or -1 without justification...
>
> Thoughts?
>
> Remko
>
> > On May 13, 2018, at 11:48, Daniel.Sun <sunlan@apache.org
> <ma...@apache.org>> wrote:
> >
> > Please see my original email:
> > "The vote is open for the next 72 hours and passes if a majority
> of at least
> > three +1 PMC votes are cast."
> >
> > Cheers,
> > Daniel.Sun
> >
> >
> >
> >
> > --
> > Sent from:
> http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
> <http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html>
>
>
Re: [VOTE] Support Java-like array
Posted by Paul King <pa...@asert.com.au>.
My understanding is that there is some flexibility when asking for votes so
long as it is clear up front what the expectation is, see e.g. [1]. Even
though there are numerous generic Apache sites with similar descriptions, I
was thinking of adding some more content in some of our pages to summarise
the most relevant information for our project. I was thinking of some
additional wording to the "Contributing code" section of the website to
indicate that typically committers should be following the same guidelines
(creating PRs etc.) for any significant code change as for people without
committer status. Also, I was going to add some wording somewhere around
our typical conventions for voting. Something like:
We strongly value keeping consensus within the project. Sometimes consensus
is obvious from general discussions or informal +1s in PRs or Jira issues.
For significant changes within PRs or Jiras, it is good to send an
informational to the dev mailing list in any case. When consensus is not
obvious or for potentially contentious changes, emails with a [VOTE] in the
subject line are a good way to ascertain consensus. Typical scenarios are:
* [VOTE] for a release - requires 3 more binding +1 votes than -1 votes (no
veto capability)
* [VOTE] for code change - requires 3 binding +1s but can be vetoed with a
single -1 binding vote
* [VOTE][LAZY] for code change - assumes absence of a vote is a +1 (but
you'd normally want at least one binding +1 so best to wait a bit longer if
you don't have at least one) but can be vetoed with a single -1 binding vote
A committer creating a PR request is similar to [VOTE][LAZY].
72 hours is the minimum for such votes but there is no maximum time delay -
though waiting too long isn't a good idea since the circumstances which
lead to earlier +1s might have changed.
If anyone has improvements for this wording, let me know.
[1] https://www.apache.org/foundation/voting.html
Cheers, Paul.
On Sun, May 13, 2018 at 2:20 PM, Remko Popma <re...@gmail.com> wrote:
> That’s probably why over at Log4j we use slightly different language for
> voting:
>
> “The vote will remain open for 72 hours (or more if required). At least 3
> +1 votes ...”
>
> It seems unfair that by not participating, it is possible to essentially
> vote -0 or -1 without justification...
>
> Thoughts?
>
> Remko
>
> > On May 13, 2018, at 11:48, Daniel.Sun <su...@apache.org> wrote:
> >
> > Please see my original email:
> > "The vote is open for the next 72 hours and passes if a majority of at
> least
> > three +1 PMC votes are cast."
> >
> > Cheers,
> > Daniel.Sun
> >
> >
> >
> >
> > --
> > Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: [VOTE] Support Java-like array
Posted by Remko Popma <re...@gmail.com>.
That’s probably why over at Log4j we use slightly different language for voting:
“The vote will remain open for 72 hours (or more if required). At least 3 +1 votes ...”
It seems unfair that by not participating, it is possible to essentially vote -0 or -1 without justification...
Thoughts?
Remko
> On May 13, 2018, at 11:48, Daniel.Sun <su...@apache.org> wrote:
>
> Please see my original email:
> "The vote is open for the next 72 hours and passes if a majority of at least
> three +1 PMC votes are cast."
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by "Daniel.Sun" <su...@apache.org>.
Please see my original email:
"The vote is open for the next 72 hours and passes if a majority of at least
three +1 PMC votes are cast."
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by Remko Popma <re...@gmail.com>.
Didn’t see a requirement for three +1 votes anywhere...
Paul asked for “I would like to see some more PMC votes for this proposal.”
Since then, two PMC members voted, one +1 and one +0.
Seems sufficient to me... Am I wrong?
PMC members, if you feel differently, could you please add your vote?
Remko
> On May 13, 2018, at 11:16, Daniel.Sun <su...@apache.org> wrote:
>
> Hi Remko,
>
> Here are Groovy PMC members
> http://people.apache.org/phonebook.html?pmc=groovy
>
> As you can see, PMC member Paul and John vote +1, Guillaume vote +0,
> other PMC members does not vote... so
> the GEP gets only two +1 from PMC members...
>
>
> Cheers,
> Daniel.Sun
>
>
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Remko,
Here are Groovy PMC members
http://people.apache.org/phonebook.html?pmc=groovy
As you can see, PMC member Paul and John vote +1, Guillaume vote +0,
other PMC members does not vote... so
the GEP gets only two +1 from PMC members...
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by Remko Popma <re...@gmail.com>.
Why? I count three +1 and one +0 votes.
Remko
> On May 13, 2018, at 2:21, Daniel.Sun <su...@apache.org> wrote:
>
> Hi Paul,
>
> The relevant JIRA ticket has been closed as the GEP fails to get three
> +1 from PMC members.
>
> P.S. I seldom use arrays directly but for performance.
>
> Cheers,
> Daniel.Sun
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by "Daniel.Sun" <su...@apache.org>.
Hi Paul,
The relevant JIRA ticket has been closed as the GEP fails to get three
+1 from PMC members.
P.S. I seldom use arrays directly but for performance.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by John Wagenleitner <jo...@gmail.com>.
+1
Originally was going to vote 0, but had more time to devote to looking over
the proposed PR/provisos and to consider the possible downsides.
On Mon, May 7, 2018 at 12:21 PM, Paul King <pa...@asert.com.au> wrote:
> I would like to see some more PMC votes for this proposal.
>
> On the one hand we don't like changes that aren't vetted enough, yet here
> is a proposed change that:
> * is fairly comprehensive (just lacking some doco which I have already
> identified)
> * closes some gaps in one of Groovy's design goals of making it easy to
> bring Java code to Groovy
> * has sought feedback from dev and user communities (and seems to have
> strong support from our user base)
>
> And yet, I am the only one from the PMC who has voted. I don't really care
> if the votes
> are critical and provide a good reason but at least then it shows respect
> for the time and
> energy put in to preparing a considered proposal and requesting formal
> feedback.
> I know everyone is super busy but we just aren't a big enough PMC right
> now for
> everyone to sit on the fence for proposals like this.
>
> While I don't think we need to mirror everything in Java and I don't
> personally think I will
> use this feature often in my own code, I can certainly see how new users
> to Groovy would
> find it useful and so it seems like an overall win from my point of view.
> Zero-learning curve
> from Java is one of the attractions of Groovy when marketing the language.
> This seems to
> offer a bit of an improvement in that space with low investment and low
> risk.
>
> If others can see serious flaws though, it would be good to provide the
> feedback so Daniel
> can make some progress. Or if someone can see better bang-for-buck changes
> that we
> should be making from a marketing of the language perspective, it would be
> good to pass
> those insights on so Daniel and other contributors can make best use of
> their time.
>
>
> Cheers, Paul.
>
>
> On Fri, May 4, 2018 at 11:31 PM, Paul King <pa...@asert.com.au> wrote:
>
>> I would keep discussions about warnings in a separate thread so as not to
>> derail the main topic here. If they were already widely used, it would be
>> fine to indicate that we should just add another one. But that isn't the
>> case and we'd need many discussions to do the topic justice.
>>
>> Cheers, Paul.
>>
>> On Fri, May 4, 2018 at 11:04 PM, mg <mg...@arscreat.com> wrote:
>>
>>> +1 with all that Paul says. Plus, we should support emitting a "Java
>>> compatibility / non-idiomatic-Groovy" warning here, to avoid people using
>>> this "for Java compatibility / quick/easy copy & paste porting of Java
>>> code"-only syntax when writing actual Groovy code (surprisingly not all
>>> developers read the complete documentation of a language, before they start
>>> using it, especially for something as base line as literal array syntax :-)
>>> ).
>>>
>>> With regards to Jochen's critique of warnings in general: I absolutely
>>> agree that too many / too picky warnings are bad. But obviously we cannot
>>> use an error here instead, so if we want to keep this syntax in the corner
>>> it belongs, warning about its use looks like the only option that would
>>> consistently work in practice to me...
>>> (same as potentially for Java lambda syntax, depending on whether one
>>> will be able to use 100% equivalent & concise Groovy closure syntax here
>>> instead).
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>> -------- Ursprüngliche Nachricht --------
>>> Von: "Daniel.Sun" <su...@apache.org>
>>> Datum: 04.05.18 03:38 (GMT+01:00)
>>> An: dev@groovy.incubator.apache.org
>>> Betreff: [VOTE] Support Java-like array
>>>
>>> Dear development community,
>>>
>>> In order to improve Groovy's compatibility with Java(Copy & Paste)
>>> and
>>> make Groovy more friendly to Java developers[1], I propose to support
>>> Java-like array[2][3] and start the VOTE thread for supporting Java-like
>>> array.
>>>
>>> Please vote on supporting Java-like array since Apache Groovy 3.0.0.
>>>
>>> Here are the poll results from twitter and user mailing list for
>>> your
>>> reference:
>>>
>>> Sum up the poll results
>>> 24 votes in total(including my +1)
>>> 15 +1 (62.5%)
>>> 9 0 (37.5%)
>>> 0 -1 ( 0.0%)
>>>
>>> Twitter[4]
>>> 19 votes in total(not including my +1)
>>> 58% +1,
>>> 42% 0,
>>> 0% -1
>>>
>>> User mailing list(
>>> http://groovy.329449.n5.nabble.com/Poll-About-supporting-Jav
>>> a-like-array-tt5749923.html
>>> )
>>> 4 votes in total(not including my +1)
>>> 3 +1,
>>> 1 0,
>>> 0 -1
>>>
>>> The vote is open for the next 72 hours and passes if a majority of at
>>> least
>>> three +1 PMC votes are cast.
>>>
>>> [ ] +1 Support Java-like array
>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>>> [ ] -1 Do not support Java-like array because...
>>>
>>> Here is my vote:
>>>
>>> +1
>>>
>>> Cheers,
>>> Daniel.Sun
>>> [1] http://groovy-lang.org/differences.html
>>> [2] https://github.com/apache/groovy/pull/691
>>> [3] https://issues.apache.org/jira/browse/GROOVY-8561
>>> [4] https://twitter.com/daniel_sun/status/990544485196091395
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>>
>
Re: [VOTE] Support Java-like array
Posted by MG <mg...@arscreat.com>.
On 07.05.2018 22:03, Guillaume Laforge wrote:
> I haven't voted as I'm not a big fan of adding this syntax construct.
>
> My feeling is that we shouldn't necessarily try to become a pure
> Java-superset, and it shouldn't be a goal to try more and more to
> close that gap.
Being able to write Java constructs in Groovy and incorporating the
improvements Groovy has to offer one after another was a major factor
for me, and it continues to be very helpful when introducing new
colleaugues to Groovy. If they know Java (and who does not, nowadays ?),
you can tell them: Just use what you know and - oh yea, do a search and
replace and remove all the semicolons at the end of each line, and you
can use a multiline String with embedded variables here, you might wanna
use a list literal there - and just say file.text = list.join('\n') to
write the result to a file, ...
> There are some confusing cases where (single element) array
> initializers can be confounded with closures.
>
> Also, I tend to prefer square brackets over curlies, but that's
> certainly a question of taste.
Agree with both points. I still think the plus outhweighs the minus -
see above and below.
>
> The other thing that slightly annoys me is that we're adding
> additional syntax for the same thing: array initializers, but look at
> how we added lambda notation.
> How will we explain users why we have two syntaxes for the same thing?
> Or when/why they should use one over the other?
Hence my suggestion to issue a "non-canonical Groovy / Java construct"-
warning in these cases - which everyone seems to confuse with some sort
of coding style warning, which to me it is clearly not: One just has to
ask oneself, whether anyone would have even considered voting for "...a
brand new alias for def: var !", or "...a way to write array literals,
so the look like closures: The amazing curly braces array literals
!".... (spoken with the voice of the boss from "IT Crowd", season 1 ;-) ).
(I understand that we currently don't have warnings in Groovy, but
seriously, how hard can it be to add errors which do not make the build
fail ?-) )
Cheers,
mg
Re: [VOTE] Support Java-like array
Posted by Guillaume Laforge <gl...@gmail.com>.
I haven't voted as I'm not a big fan of adding this syntax construct.
My feeling is that we shouldn't necessarily try to become a pure
Java-superset, and it shouldn't be a goal to try more and more to close
that gap.
There are some confusing cases where (single element) array initializers
can be confounded with closures.
Also, I tend to prefer square brackets over curlies, but that's certainly a
question of taste.
The other thing that slightly annoys me is that we're adding additional
syntax for the same thing: array initializers, but look at how we added
lambda notation.
How will we explain users why we have two syntaxes for the same thing? Or
when/why they should use one over the other?
I guess with 15 years involved in various ways with Groovy, I'm also
becoming more conservative with changes, and I fear that we might be making
Groovy more / too complicated.
So I will vote, but only with +0.
Guillaume
On Mon, May 7, 2018 at 9:21 PM, Paul King <pa...@asert.com.au> wrote:
> I would like to see some more PMC votes for this proposal.
>
> On the one hand we don't like changes that aren't vetted enough, yet here
> is a proposed change that:
> * is fairly comprehensive (just lacking some doco which I have already
> identified)
> * closes some gaps in one of Groovy's design goals of making it easy to
> bring Java code to Groovy
> * has sought feedback from dev and user communities (and seems to have
> strong support from our user base)
>
> And yet, I am the only one from the PMC who has voted. I don't really care
> if the votes
> are critical and provide a good reason but at least then it shows respect
> for the time and
> energy put in to preparing a considered proposal and requesting formal
> feedback.
> I know everyone is super busy but we just aren't a big enough PMC right
> now for
> everyone to sit on the fence for proposals like this.
>
> While I don't think we need to mirror everything in Java and I don't
> personally think I will
> use this feature often in my own code, I can certainly see how new users
> to Groovy would
> find it useful and so it seems like an overall win from my point of view.
> Zero-learning curve
> from Java is one of the attractions of Groovy when marketing the language.
> This seems to
> offer a bit of an improvement in that space with low investment and low
> risk.
>
> If others can see serious flaws though, it would be good to provide the
> feedback so Daniel
> can make some progress. Or if someone can see better bang-for-buck changes
> that we
> should be making from a marketing of the language perspective, it would be
> good to pass
> those insights on so Daniel and other contributors can make best use of
> their time.
>
>
> Cheers, Paul.
>
>
> On Fri, May 4, 2018 at 11:31 PM, Paul King <pa...@asert.com.au> wrote:
>
>> I would keep discussions about warnings in a separate thread so as not to
>> derail the main topic here. If they were already widely used, it would be
>> fine to indicate that we should just add another one. But that isn't the
>> case and we'd need many discussions to do the topic justice.
>>
>> Cheers, Paul.
>>
>> On Fri, May 4, 2018 at 11:04 PM, mg <mg...@arscreat.com> wrote:
>>
>>> +1 with all that Paul says. Plus, we should support emitting a "Java
>>> compatibility / non-idiomatic-Groovy" warning here, to avoid people using
>>> this "for Java compatibility / quick/easy copy & paste porting of Java
>>> code"-only syntax when writing actual Groovy code (surprisingly not all
>>> developers read the complete documentation of a language, before they start
>>> using it, especially for something as base line as literal array syntax :-)
>>> ).
>>>
>>> With regards to Jochen's critique of warnings in general: I absolutely
>>> agree that too many / too picky warnings are bad. But obviously we cannot
>>> use an error here instead, so if we want to keep this syntax in the corner
>>> it belongs, warning about its use looks like the only option that would
>>> consistently work in practice to me...
>>> (same as potentially for Java lambda syntax, depending on whether one
>>> will be able to use 100% equivalent & concise Groovy closure syntax here
>>> instead).
>>>
>>> Cheers,
>>> mg
>>>
>>>
>>> -------- Ursprüngliche Nachricht --------
>>> Von: "Daniel.Sun" <su...@apache.org>
>>> Datum: 04.05.18 03:38 (GMT+01:00)
>>> An: dev@groovy.incubator.apache.org
>>> Betreff: [VOTE] Support Java-like array
>>>
>>> Dear development community,
>>>
>>> In order to improve Groovy's compatibility with Java(Copy & Paste)
>>> and
>>> make Groovy more friendly to Java developers[1], I propose to support
>>> Java-like array[2][3] and start the VOTE thread for supporting Java-like
>>> array.
>>>
>>> Please vote on supporting Java-like array since Apache Groovy 3.0.0.
>>>
>>> Here are the poll results from twitter and user mailing list for
>>> your
>>> reference:
>>>
>>> Sum up the poll results
>>> 24 votes in total(including my +1)
>>> 15 +1 (62.5%)
>>> 9 0 (37.5%)
>>> 0 -1 ( 0.0%)
>>>
>>> Twitter[4]
>>> 19 votes in total(not including my +1)
>>> 58% +1,
>>> 42% 0,
>>> 0% -1
>>>
>>> User mailing list(
>>> http://groovy.329449.n5.nabble.com/Poll-About-supporting-Jav
>>> a-like-array-tt5749923.html
>>> )
>>> 4 votes in total(not including my +1)
>>> 3 +1,
>>> 1 0,
>>> 0 -1
>>>
>>> The vote is open for the next 72 hours and passes if a majority of at
>>> least
>>> three +1 PMC votes are cast.
>>>
>>> [ ] +1 Support Java-like array
>>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>>> [ ] -1 Do not support Java-like array because...
>>>
>>> Here is my vote:
>>>
>>> +1
>>>
>>> Cheers,
>>> Daniel.Sun
>>> [1] http://groovy-lang.org/differences.html
>>> [2] https://github.com/apache/groovy/pull/691
>>> [3] https://issues.apache.org/jira/browse/GROOVY-8561
>>> [4] https://twitter.com/daniel_sun/status/990544485196091395
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>>
>>
>>
>
--
Guillaume Laforge
Apache Groovy committer & PMC Vice-President
Developer Advocate @ Google Cloud Platform
Blog: http://glaforge.appspot.com/
Twitter: @glaforge <http://twitter.com/glaforge>
Re: [VOTE] Support Java-like array
Posted by Paul King <pa...@asert.com.au>.
I would like to see some more PMC votes for this proposal.
On the one hand we don't like changes that aren't vetted enough, yet here
is a proposed change that:
* is fairly comprehensive (just lacking some doco which I have already
identified)
* closes some gaps in one of Groovy's design goals of making it easy to
bring Java code to Groovy
* has sought feedback from dev and user communities (and seems to have
strong support from our user base)
And yet, I am the only one from the PMC who has voted. I don't really care
if the votes
are critical and provide a good reason but at least then it shows respect
for the time and
energy put in to preparing a considered proposal and requesting formal
feedback.
I know everyone is super busy but we just aren't a big enough PMC right now
for
everyone to sit on the fence for proposals like this.
While I don't think we need to mirror everything in Java and I don't
personally think I will
use this feature often in my own code, I can certainly see how new users to
Groovy would
find it useful and so it seems like an overall win from my point of view.
Zero-learning curve
from Java is one of the attractions of Groovy when marketing the language.
This seems to
offer a bit of an improvement in that space with low investment and low
risk.
If others can see serious flaws though, it would be good to provide the
feedback so Daniel
can make some progress. Or if someone can see better bang-for-buck changes
that we
should be making from a marketing of the language perspective, it would be
good to pass
those insights on so Daniel and other contributors can make best use of
their time.
Cheers, Paul.
On Fri, May 4, 2018 at 11:31 PM, Paul King <pa...@asert.com.au> wrote:
> I would keep discussions about warnings in a separate thread so as not to
> derail the main topic here. If they were already widely used, it would be
> fine to indicate that we should just add another one. But that isn't the
> case and we'd need many discussions to do the topic justice.
>
> Cheers, Paul.
>
> On Fri, May 4, 2018 at 11:04 PM, mg <mg...@arscreat.com> wrote:
>
>> +1 with all that Paul says. Plus, we should support emitting a "Java
>> compatibility / non-idiomatic-Groovy" warning here, to avoid people using
>> this "for Java compatibility / quick/easy copy & paste porting of Java
>> code"-only syntax when writing actual Groovy code (surprisingly not all
>> developers read the complete documentation of a language, before they start
>> using it, especially for something as base line as literal array syntax :-)
>> ).
>>
>> With regards to Jochen's critique of warnings in general: I absolutely
>> agree that too many / too picky warnings are bad. But obviously we cannot
>> use an error here instead, so if we want to keep this syntax in the corner
>> it belongs, warning about its use looks like the only option that would
>> consistently work in practice to me...
>> (same as potentially for Java lambda syntax, depending on whether one
>> will be able to use 100% equivalent & concise Groovy closure syntax here
>> instead).
>>
>> Cheers,
>> mg
>>
>>
>> -------- Ursprüngliche Nachricht --------
>> Von: "Daniel.Sun" <su...@apache.org>
>> Datum: 04.05.18 03:38 (GMT+01:00)
>> An: dev@groovy.incubator.apache.org
>> Betreff: [VOTE] Support Java-like array
>>
>> Dear development community,
>>
>> In order to improve Groovy's compatibility with Java(Copy & Paste)
>> and
>> make Groovy more friendly to Java developers[1], I propose to support
>> Java-like array[2][3] and start the VOTE thread for supporting Java-like
>> array.
>>
>> Please vote on supporting Java-like array since Apache Groovy 3.0.0.
>>
>> Here are the poll results from twitter and user mailing list for your
>> reference:
>>
>> Sum up the poll results
>> 24 votes in total(including my +1)
>> 15 +1 (62.5%)
>> 9 0 (37.5%)
>> 0 -1 ( 0.0%)
>>
>> Twitter[4]
>> 19 votes in total(not including my +1)
>> 58% +1,
>> 42% 0,
>> 0% -1
>>
>> User mailing list(
>> http://groovy.329449.n5.nabble.com/Poll-About-supporting-
>> Java-like-array-tt5749923.html
>> )
>> 4 votes in total(not including my +1)
>> 3 +1,
>> 1 0,
>> 0 -1
>>
>> The vote is open for the next 72 hours and passes if a majority of at
>> least
>> three +1 PMC votes are cast.
>>
>> [ ] +1 Support Java-like array
>> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
>> [ ] -1 Do not support Java-like array because...
>>
>> Here is my vote:
>>
>> +1
>>
>> Cheers,
>> Daniel.Sun
>> [1] http://groovy-lang.org/differences.html
>> [2] https://github.com/apache/groovy/pull/691
>> [3] https://issues.apache.org/jira/browse/GROOVY-8561
>> [4] https://twitter.com/daniel_sun/status/990544485196091395
>>
>>
>>
>>
>>
>> --
>> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>>
>
>
Re: [VOTE] Support Java-like array
Posted by Paul King <pa...@asert.com.au>.
I would keep discussions about warnings in a separate thread so as not to
derail the main topic here. If they were already widely used, it would be
fine to indicate that we should just add another one. But that isn't the
case and we'd need many discussions to do the topic justice.
Cheers, Paul.
On Fri, May 4, 2018 at 11:04 PM, mg <mg...@arscreat.com> wrote:
> +1 with all that Paul says. Plus, we should support emitting a "Java
> compatibility / non-idiomatic-Groovy" warning here, to avoid people using
> this "for Java compatibility / quick/easy copy & paste porting of Java
> code"-only syntax when writing actual Groovy code (surprisingly not all
> developers read the complete documentation of a language, before they start
> using it, especially for something as base line as literal array syntax :-)
> ).
>
> With regards to Jochen's critique of warnings in general: I absolutely
> agree that too many / too picky warnings are bad. But obviously we cannot
> use an error here instead, so if we want to keep this syntax in the corner
> it belongs, warning about its use looks like the only option that would
> consistently work in practice to me...
> (same as potentially for Java lambda syntax, depending on whether one will
> be able to use 100% equivalent & concise Groovy closure syntax here
> instead).
>
> Cheers,
> mg
>
>
> -------- Ursprüngliche Nachricht --------
> Von: "Daniel.Sun" <su...@apache.org>
> Datum: 04.05.18 03:38 (GMT+01:00)
> An: dev@groovy.incubator.apache.org
> Betreff: [VOTE] Support Java-like array
>
> Dear development community,
>
> In order to improve Groovy's compatibility with Java(Copy & Paste) and
> make Groovy more friendly to Java developers[1], I propose to support
> Java-like array[2][3] and start the VOTE thread for supporting Java-like
> array.
>
> Please vote on supporting Java-like array since Apache Groovy 3.0.0.
>
> Here are the poll results from twitter and user mailing list for your
> reference:
>
> Sum up the poll results
> 24 votes in total(including my +1)
> 15 +1 (62.5%)
> 9 0 (37.5%)
> 0 -1 ( 0.0%)
>
> Twitter[4]
> 19 votes in total(not including my +1)
> 58% +1,
> 42% 0,
> 0% -1
>
> User mailing list(
> http://groovy.329449.n5.nabble.com/Poll-About-supporting-Java-like-array-
> tt5749923.html
> )
> 4 votes in total(not including my +1)
> 3 +1,
> 1 0,
> 0 -1
>
> The vote is open for the next 72 hours and passes if a majority of at least
> three +1 PMC votes are cast.
>
> [ ] +1 Support Java-like array
> [ ] 0 I don't have a strong opinion about this, but I assume it's ok
> [ ] -1 Do not support Java-like array because...
>
> Here is my vote:
>
> +1
>
> Cheers,
> Daniel.Sun
> [1] http://groovy-lang.org/differences.html
> [2] https://github.com/apache/groovy/pull/691
> [3] https://issues.apache.org/jira/browse/GROOVY-8561
> [4] https://twitter.com/daniel_sun/status/990544485196091395
>
>
>
>
>
> --
> Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
>
Re: [VOTE] Support Java-like array
Posted by "Daniel.Sun" <su...@apache.org>.
Kotlin is a great language, but I do not like its syntax...
Groovy's STC will be better in the next releases. I wish we could fix most
of issues before 3.0.0 GA. Currently there are about 70 issues about STC
being open to fix.
Cheers,
Daniel.Sun
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Re: [VOTE] Support Java-like array
Posted by mg <mg...@arscreat.com>.
+1 with all that Paul says. Plus, we should support emitting a "Java compatibility / non-idiomatic-Groovy" warning here, to avoid people using this "for Java compatibility / quick/easy copy & paste porting of Java code"-only syntax when writing actual Groovy code (surprisingly not all developers read the complete documentation of a language, before they start using it, especially for something as base line as literal array syntax :-) ).
With regards to Jochen's critique of warnings in general: I absolutely agree that too many / too picky warnings are bad. But obviously we cannot use an error here instead, so if we want to keep this syntax in the corner it belongs, warning about its use looks like the only option that would consistently work in practice to me...(same as potentially for Java lambda syntax, depending on whether one will be able to use 100% equivalent & concise Groovy closure syntax here instead).
Cheers,mg
-------- Ursprüngliche Nachricht --------Von: "Daniel.Sun" <su...@apache.org> Datum: 04.05.18 03:38 (GMT+01:00) An: dev@groovy.incubator.apache.org Betreff: [VOTE] Support Java-like array
Dear development community,
In order to improve Groovy's compatibility with Java(Copy & Paste) and
make Groovy more friendly to Java developers[1], I propose to support
Java-like array[2][3] and start the VOTE thread for supporting Java-like
array.
Please vote on supporting Java-like array since Apache Groovy 3.0.0.
Here are the poll results from twitter and user mailing list for your
reference:
Sum up the poll results
24 votes in total(including my +1)
15 +1 (62.5%)
9 0 (37.5%)
0 -1 ( 0.0%)
Twitter[4]
19 votes in total(not including my +1)
58% +1,
42% 0,
0% -1
User mailing list(
http://groovy.329449.n5.nabble.com/Poll-About-supporting-Java-like-array-tt5749923.html
)
4 votes in total(not including my +1)
3 +1,
1 0,
0 -1
The vote is open for the next 72 hours and passes if a majority of at least
three +1 PMC votes are cast.
[ ] +1 Support Java-like array
[ ] 0 I don't have a strong opinion about this, but I assume it's ok
[ ] -1 Do not support Java-like array because...
Here is my vote:
+1
Cheers,
Daniel.Sun
[1] http://groovy-lang.org/differences.html
[2] https://github.com/apache/groovy/pull/691
[3] https://issues.apache.org/jira/browse/GROOVY-8561
[4] https://twitter.com/daniel_sun/status/990544485196091395
--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html