[
https://issues.apache.org/jira/browse/GROOVY-8329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16653824#comment-16653824
]
Eric Holley commented on GROOVY-8329:
-------------------------------------
I've been using Groovy for a number of years now (love it) and I have to say
that I @CompileStatic most all of my classes. I have a suggestion for a future
release of Groovy regarding the static/dynamic compilation issue. Currently, it
is the responsibility of the object caller (methods, getters, setters) to
determine if code should be compiled dynamically or statically. This decision
requires knowledge of the called class with regard to if it implements dynamic
behavior or not. It would seem to me that if classes that implement dynamic
behavior were annotated (e.g. @Dynamic,) the compiler could make the decision
of how to call the object for the user. This would allow the compiler to
generate static calling code for all referenced non-dynamic classes and dynamic
calls for those classes specifically marked as @Dynamic. By dynamic behavior, I
mean that the class uses the MOP to trap method calls and either override their
implementation or provide implementations for missing methods. A further
improvement would be to add a parameter to @Dynamic that would give the class
writer the ability to indicate that defined getters/setters/methods should be
treated as static calls and never overridden by a dynamic call trap. This would
allow @Dynamic classes to have static behavior for defined g/s/methods. This
could be fine-tuned by allowing defined g/s/methods to be annotated with
@Dynamic to exclude them from this static behavior. Of course this would all
have to be though out to ensure there is no legacy code breakage (compiler
switches?) If I'm missing something here, please chime in, but I believe that
this is something that could be doable.
> 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
> Priority: Major
>
> 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
(v7.6.3#76005)
