What I would actually have hoped for in Groovy 3:
1. Field/variable type inference outside of flow typing, especially in
the case where the variable/field is final.
2. Covariance
These are things I encounter constantly as a problem as soon as I switch
another class to @CompileStatic.
Having to e.g. explicitly give the type of ever final field in a class,
even though it could easily be deduced from the RHS expression (as I
have argued before, no need to be fancy here and implement some clever
crystal ball algoritms: If the RHS is a ctor call ("new Foo(...)") or a
method that returns Foo then the LHS type is Foo) is so un-Groovy.
Does it really make sense to never implement this, just because one
would like to have a super-clever variant of it, which most likely will
never manifest ?
The same goes for the classical covariance example of
Iterable<ChildOfFoo> not being a subtype of Iterable<Foo>.
And its (perceived) relative, where
class <T extends Foo> Foos<T> implements Iterable<T> { ... }
currently leads to Foos<ChildOfFoo> being assumed to have members of
type Object...
Cheers,
mg
On 24/05/2019 02:27, Paul King wrote:
Hi everyone,
I plan to do a beta-2 of 3.0.0 in a few weeks and then hopefully we'll
start the ramp down to final with one or more RCs. When we get to the
RCs stage, I'll make a 3_0_X branch. At this stage I don't foresee a
3.1 version but we can certainly do one if desired/needed. So, I'll
make master Groovy 4 at that point.
What do people think about changing our maven coordinates with Groovy
4 from org.codehaus.groovy to org.apache.groovy?
Also, if you have anything you'd particularly like to see in Groovy 4,
please discuss. I'll have a slide on potential things in Groovy 4 in
my gr8conf talk next week. I'd like to include as many sensible ideas
as possible to make use of the opportunity to garner feedback on what
our users are looking for.
Some of the things currently on my list:
* improved module support (including split package final steps)
* further invoke dynamic improvements (including deferred merge to
indy only)
* stream-based replacements for XmlSlurper et al
* groovydoc rework (assuming we manage to finish porting the current
groovydoc to 3)
* improved built-in type checking extensions (@NonNull et al)
Let me know what is on your lists of things you'd like to see.
Cheers, Paul.
