groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <tibokr...@googlemail.com>
Subject Re: What the... static compile by default
Date Fri, 11 May 2018 01:42:33 GMT
It seems a bit weird to leave this thread dangling after the dramatic
entry scene.

The activity on master branch seems to indicate some changes were decided:

danielsun1106 committed 2 days ago : Revert "GROOVY-8543: Support
setting compileStatic by default via sys…
danielsun1106 committed 18 hours ago : GROOVY-7204: Static type
checking and compilation fail when multiple …
danielsun1106 committed 14 hours ago : Simplify finding generics
implementation class

However, the meta-concern by Cedric was not addressed it seems. Why is
anyone directly working on the master branch of groovy?
Is there a technical reason for this, rather than using feature
branches, code reviews, and merge approvals?
Or is it just that nobody would have time to review in a timely
fashion anyway, so it's either that or zero progress?


On Tue, May 8, 2018 at 7:43 AM, MG <mgbiz@arscreat.com> wrote:
> On 07.05.2018 17:54, Cédric Champeau wrote:
>>
>> I'd typically very much prefer a custom file extension for example.
>
>
> That would be my preferred way to give anyone a simple mean to choose static
> compilation as the default for a Groovy file. Afair the counter argument
> was, that Groovy compiles any file with any extension in dynamic mode by
> default, so this might be a breaking change if someone has used the picked
> extension for his files. Groovy 3.0 might be the right spot to introduce
> something like this, since there will be breaking changes anyway...
>
>> That said, since I'm not contributing code anymore (my last contribution
>> was rewriting most of the build, which I hope was helpful),
>
>
> Any improvement/speedup of the Gradle build was _definitely_ appreciated :-)
>
>> I'm happy to step down and let you work as you wish.
>
>
> This is tricky: One cannot agree with just any direction someone who invests
> the time to advance Groovy wants to take it too, that would be taking
> Doocracy too far, imho, and might lead to a Groovy which is much worse than
> it could be.
> In this particular case I am torn: I think we could definitely live with the
> system property, I don't feel there is a large probability that it will
> break anything. On the other hand, using the existing mechanism, or
> introducing a static compilation source file extension, or a compiler switch
> seem to me to be the better choices - but maybe Daniel can explain why he
> went with the property approach ?-)
>
> Cheers,
> mg
>
>
>

Mime
View raw message