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:
On Wed, 2018-05-16 at 23:17 +0200, MG wrote:
> Thank you Jochen and Cédric for explaining you rationale. It is funny,
> because I always thought keeping Groovy as close to Java as possible was
> a given. Evidently it is not...
>
[…]
I 2003/2004 having a dynamic version of Java was great stuff.
On 16.05.2018 23:17, MG wrote:
[...]
Btw, Jochen, can you give an example for using this syntax for array
type annotation arguments, which you mentioned a week or so back ?
basically two variants:
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
or maybe:
Am 15.05.2018 um 08:03 schrieb mg:
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..."
I did not vote +1 because I find it surplus, on the other hand I do not
really want to block it if others are eager
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>
&
@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 throug
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
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
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
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?
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
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?
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:
Why? I count three +1 and one +0 votes.
Remko
> On May 13, 2018, at 2:21, Daniel.Sun 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.
>
>
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
k 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üng
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
ant 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%
ly 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
>>
>>
&
00% equivalent & concise Groovy closure syntax
here instead).
Cheers,mg
Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org>
Datum: 04.05.18 03:38 (GMT+01:00) An: d...@groovy.incubator.apache.org
Betreff: [VOTE] Support Java-like array
Dear deve
00% equivalent & concise Groovy closure syntax
here instead).
Cheers,mg
Ursprüngliche Nachricht Von: "Daniel.Sun" <sun...@apache.org>
Datum: 04.05.18 03:38 (GMT+01:00) An: d...@groovy.incubator.apache.org
Betreff: [VOTE] Support Java-like array
Dear deve
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
+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
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
24 matches
Mail list logo