Hi,
before I create change requests, I wanted to ask for some quick feedback
on the following potential new Groovy features (I apologize beforehand,
if any of these are already covered in some way, and I missed it, or if
they have been discussed before, etc - just throwing ideas that I find
useful out there :-) ):
1. Named Paramters: I already posted that feature request here. The
most plain vanilla support (support the <name>:<value>,
<name>:<value>, ... syntax to give named ctor/method args) would
already cover 99% of applications here, I think. The imho most
problematic feedback was external libraries without debug
information - my question would be how frequently such libraries
occur in practice (I personally have never pressed Ctrl+B in
IntelliJ and not gotten a method decompile result with parameter
names) ?
2. Support making all method/ctor parameters final by default through
"autofinal" Groovy compiler flag:
Foo(int x, String s) { // final keyword is auto added to all
parameters, if compiler flag is set, i.e. this automatically becomes
Foo(final int x, final String s)
this.x = x; this.s
}
Rationale: Even if Groovy source samples use def instead of final a
lot, parameters (and variables) are, according to my experience,
most of the time actually final in practice (In the few cases where
one needs to modify a parameter, it can immediately be assigned to a
variable). This feature would reduce the source code clutter that
comes from the need to qualify parameters as final all the time.
3. Deduce the type of final fields from their assigned value:
class Foo {
final device = new PrinterDevice(...) // device field will have type
PrinterDevice instead of Object when reflection is used on class Foo
}
Rationale: While IntelliJ does a good job at deducing the type of
final fields, it would still be better if the Groovy language itself
would use the more specialized type here, for e.g. reflection purposes
4. Introduce a "var" (o.s.) keyword that allows deduction of type
through assignment:
var device = new PrinterDevice(...) // device variable will have
type PrinterDevice without the need to explictely state that
Rationale: This is a well known feature of other languages, that
reduces the need to explictely define the type of variables.
5. Always allow ctor calls without new keyword:
final foo = Foo("abc") // creates a new Foo instance by calling Foo
class ctor with signature
Rationale: new keyword was necessary in C++ to distinguish heap vs
stack variable allocation. No such need exists in Groovy, so the
keyword just clutters the source code. Naming convention of method
names being always lowercase prevents name clashes with methods.
6. "Variable plus Name" support: One of the most useful macros I used
in C++ was NV(x), where I passed a variable, and created a
NamedVariable instance, which was automatically passed the name and
the value of the variable (through simple macro stringify). I would
love to see something similar in Groovy.
Rationale: Most important application is DRY creation of debug
output, e.g.:
println NV(longVariableName) // equivalent result to println
"longVariableName=$longVariableName" avoding the potential classical
copy & paste error "longVariableName=$longrVariableName"
7. Support break/continue to work as if a closure was a block
construct, e.g. through an annotation on the Closure parameter:
sqe.forEachRow("select * from PERSON") { final row ->
if(row.TAG == 0) { continue } // Move to next iteration in
forEachRow iteration over PERSON table
if(row.TAG == 1) { break } // Return form closure & return from
forEachRow (effectively stopping to iterate over PERSON table rows,
continuing after the method call)
}
Rationale: Groovy's support for giving a Closure as the last
argument outside of the parameter brackets is one of its most neat
features. Supporting break/continue with expected (least surprise)
semantics inside of such closures, would make this feature complete.
(Note: I have implemented support for a "BreakLoopException" in my
code, so that the closure body can signal a break to e.g.
forEachRow, but that is still quite an akward solution, that breaks
the illusion that forEachRow works like a regular for-each statement)
8. CompileStatic byte code call compatibility with Java: I have
included this, since I saw it on the mailing list here, and I always
tell everyone that Groovy is basically a drop in replacement for
Java, which in this case, if obfuscation is part of the game, does
not seem to be the case (in addition my son has also started to mod
Minecraft a bit, and I wanted to use this to introduce him to Groovy
- after he has suffered through a bit of Java ;-) ).
mg
