Dynamic type in Groovy is useful in mixing dynamic and static code. Consider
the case of parsing a JSON/XML document, where we don't wish to develop a
complex WSDL/JAXB/Jackson model. However the results of the parsing call
utility methods of known types and dealing with objects of known types. In our
case it is nice to know at compile time if I refactor a util method for
example, that I forgot to change a call site. In the below example, we could
statically compile the call to nameFromLanguage and the call to the new
ProgrammingLanguage. callWebService is considered to return a "dynamic" type
which follows standard Groovy MOP and generates standard dynamic call sites.
The result of any property or method on a "dynamic" type is of type "dynamic",
with the exception of methods available on all objects like toString and
hashCode. Likewise, the parameter to "each", "collect" and such on a dynamic
type is of "dynamic" type. But all other rules of @CompileStatic are followed.
Bonus points if "dynamic" can be an actual type in Groovy such that you can
have Map<String, Dynamic>. Casting a dynamic type to a concrete type
re-activates the static checking and is required to call statically-checked
methods. A point of discussion would be if an implicit cast of "dynamic" to any
concrete type is possible (for example when I know that "it.language" below
must be a String) -- in this case static compiler would generate a standard
Java cast resulting in ClassCastException if necessary. In an ideal alternate
Groovy universe, Groovy is always statically compiled unless you define
something with "def" in which case Groovy MOP is used (and a variant of def
allowed on an method declaration to allow for run-time type resolution to
totally eliminate instanceof even in "static" code by generating a synthetic
overload taking all Object parameter that uses MOP to call the right variant).
def callWebService() {
[[language: 'Groovy', versions: [1, 2, 3]],
[language: 'C', versions: [1, 2, 3]]]
}
//Some complex util method
String nameFromLanguage(it) { it as String }
@Immutable class ProgrammingLanguage { String name; String version }
List<ProgrammingLanguage> getProgrammingLanguages() {
List<ProgrammingLanguage> ret = []
callWebService().each {
def language = nameFromLanguage(it.language as String)
ret += it.versions.collect { version ->
new ProgrammingLanguage(name: language, version:
version as String)
}
}
return ret
}
In terms of improvements, bug fixing is the biggest one. It is disappointing
when I advocate strongly for Groovy then run into a static compiler bug, or
have to put in an extra cast I shouldn't, or have to bring out a decompiler,
none of which I've ever had to do in Java but have had to do a handful of times
in Groovy. Yes, the improvements since CompileStatic started in 2.x to 2.4.7
are drastic, but people have extremely high expectations of their compilers. My
only other wish, not to any fault of Groovy team, is that I wish Groovy support
in IntelliJ was as good as Java -- I run into bugs there from time to time.
JetBrains is fairly responsive most of the time to Groovy defects, but there
have been regressions (such as a near-total loss of rendering docs), and still
currently bugs like some failures when doing basic refactoring and even in
2016.2 since the regression of groovydoc they still have not re-fixed {@link
abc} so any such links are simply deleted in any doc output. IDEA is in no way
responsibility of Groovy team but I mention it as one of the three areas that
impact the total end-to-end Groovy experience.
Jason
-----Original Message-----
From: Jochen Theodorou [mailto:[email protected]]
Sent: Monday, June 27, 2016 4:52 PM
To: [email protected]
Subject: Re: Is it possible to enable CompileStatic for an entire project
On 27.06.2016 21:47, Winnebeck, Jason wrote:
> What I'd like to see in Groovy or Kotlin is a way to be a static language but
> declare a type as dynamic or a certain type of "dynamic" (like gpath/xml
> where you know you are accessing map of maps).
why is as method level annotation not good enough for you?
[...]
> So now we are down to asking for improvements to the static side of Groovy so
> we can have it all :).
and what, besides bug fixing, improvements are you thinking of?
bye Jochen
----------------------------------------------------------------------
This email message and any attachments are for the sole use of the intended
recipient(s). Any unauthorized review, use, disclosure or distribution is
prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message and any attachments.
