[jira] [Comment Edited] (GROOVY-8329) Consider statically typed/compiled as default for Groovy 3.0

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Comment Edited] (GROOVY-8329) Consider statically typed/compiled as default for Groovy 3.0

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/GROOVY-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16202015#comment-16202015 ]

Paul King edited comment on GROOVY-8329 at 10/12/17 2:31 PM:
-------------------------------------------------------------

I wouldn't phrase it that we want less convenient static support than you (when appropriate) but just not wanting to give up the dynamic capabilities of Groovy either. The current "intrinsic feature" of the file is the CompileStatic annotation at the top. We might eventually support special filenames but are just conservative in introducing such a change.

Wrt the @author tags, Apache leave it up to each PMC to decide whether to have them or not but they strongly recommend avoiding those tags and so do many agile folks these days. It's potentially controversial but some of the links are interesting:

[https://marc.info/?l=xml-cocoon-dev&m=107787986409413&w=2]
[http://opensource.com/law/14/2/copyright-statements-source-files]
[https://issues.apache.org/jira/issues/?jql=text%20~%20%22%40author%20tags%22]
[http://vojtechruzicka.com/stop-using-javadoc-author-tag/]
[https://stackoverflow.com/questions/17269843/javadoc-author-tag-good-practices]
[https://www.theinquirer.net/inquirer/news/1037207/apache-enforces-the-removal-of-author-tags]
[http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_09_22.txt] (read 7F)

TLDR; having them violates DRY. Why have inaccurate out-of-date metadata when your repo gives accurate info in one place - and graphs showing all contributors if you want. Plus there is an aspect of code ownership by the whole community and not wanting to scare potential contributors away because someone else "owns" a file plus I think there are legal ramifications (you might get sued in some countries when all you did was add a few comments into a file!). As per Apache recommendations, for any significant contribution, we should add folks into the pomconfigurer.gradle file.


was (Author: paulk):
I wouldn't phrase it that we want less convenient static support than you (when appropriate) but just not wanting to give up the dynamic capabilities of Groovy either. The current "intrinsic feature" of the file is the CompileStatic annotation at the top. We might eventually support special filenames but are just conservative in introducing such a change.

Wrt the @author tags, Apache leave it up to each PMC to decide whether to have them or not but they strongly recommend avoiding those tags and so do many agile folks these days. It's potentially controversial but some of the links are interesting:

[https://marc.info/?l=xml-cocoon-dev&m=107787986409413&w=2]
[http://opensource.com/law/14/2/copyright-statements-source-files]
[https://issues.apache.org/jira/issues/?jql=text%20~%20%22remove%20%40author%20tags%22]
[https://issues.apache.org/jira/issues/?jql=text%20~%20%22%40author%20tags%22]
[http://vojtechruzicka.com/stop-using-javadoc-author-tag/]
[https://stackoverflow.com/questions/17269843/javadoc-author-tag-good-practices]
[https://www.theinquirer.net/inquirer/news/1037207/apache-enforces-the-removal-of-author-tags]
[http://www.apache.org/foundation/records/minutes/2004/board_minutes_2004_09_22.txt] (read 7F)

TLDR; having them violates DRY. Why have inaccurate out-of-date metadata when your repo gives accurate info in one place - and graphs showing all contributors if you want. Plus there is an aspect of code ownership by the whole community and not wanting to scare potential contributors away because someone else "owns" a file plus I think there are legal ramifications (you might get sued in some countries when all you did was add a few comments into a file!). As per Apache recommendations, for any significant contribution, we should add folks into the pomconfigurer.gradle file.

> Consider statically typed/compiled as default for Groovy 3.0
> ------------------------------------------------------------
>
>                 Key: GROOVY-8329
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8329
>             Project: Groovy
>          Issue Type: New Feature
>            Reporter: Endre StĂžlsvik
>
> Personally, I do not understand why anyone would ever want to drop typing from JVM based languages (or in any other language, for that matter). Thus, I only started using Groovy "for real" when I discovered the @CompileStatic annotation, which really made everything great!
> If I could choose, I'd go for statically typed by default, with @DynamicCompile or somesuch as an annotation I could turn on for methods that uses the XML parsing features etc.
> To me, it seems like more and more people are realizing that statically typed languages is the way to go, notice e.g. TypeScript, Facebook's retrofitting of types onto PHP with Hack, and even PHP's own typing in PHP 7.
> Now with Kotlin joining the fray of JVM-based languages, whose literally first two words on the wepage is "statically typed", getting special support in Spring, and - notably - getting full support in Gradle, I'd say that this applies more than ever. If Groovy "looses Gradle" to Kotlin due to the ability to get a statically typed build script (oh, the joy!), I believe Groovy will have a much harder time attracting new users. Turning Groovy into one of the statically typed JVM languages, instead of hampering users with "everything is an Object"-based runtime resolution, will increase the appeal of the language.
> The 3.0 can be a great point to change this. It could of course be reverted back to previous logic by some -D switch (would need support in IDEs too, I guess), or by sticking some magic "whole-sale annotation" at the top of the source file, or something like this.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)