Hi,
having recently explained why Groovy is my language of choice got me
thinking about the few areas of Groovy where I personally wish for / see
the potential for improvement during my daily development tasks.
I will start off with named paramters support, a topic that has been
moving more into my consciousness as the framework I develop at work
grew larger over time: I feel that the current named parameter support I
am aware of
(http://groovy-lang.org/objectorientation.html#_named_argument_constructor
/ http://groovy-lang.org/objectorientation.html#_named_arguments ) is a
limited feature that fit relatively well with a purely dynamic language,
but is not nearly as well rounded / powerful as in other languages.
Do you have any plans to support named parameters such as they exist
e.g. in PL/SQL (to be honest, I never expected I would ever quote PL/SQL
as a language that is superior to Groovy in any aspect before I thought
about this ;-) ), where named paramters are just a convenient (and
safer) way to call a callable, without loosing type safety, which works
in a purely static manner, and without requiring a method to explicitely
deal with a Map as its argument.
In short, a way to call any Groovy method/ctor with a syntax like:
class Processor {
Processor(String name, boolean writeableQ = false, boolean
extendableQ = true, Number id = null, Worker defaultWorker = null,
Closure logCls = { println it }) { ... }
work(Worker worker = null, boolean dryRunQ = false, int
maxNrRetries = 10, boolean overwriteQ = false) { ... }
}
final processor= new Processor(name:"Task 1", id:1234) { log.debug "T1:
$it" } // Closure as last argument can still be given outside of brackets
processor.work(maxNrRetries:99)
The grooviest thing of all would be, if there would be a way to keep the
flexibility of the map argument, and combine it with the named
arguments, to be able to e.g. define a different default set of default
values for a method/ctor. E.g.
static ParametersMap getDebugWorkParams() {
return [ worker:dummyWorker, dryRunQ:true, maxNrRetries:0,
overwriteQ:true ]
}
processor.work(*(debugWorkParams + [worker:logOnlyWorker,
maxNrRetries:3])) // dryRunQ=true and overwriteQ=true comes from
debugWorkParams; worker and maxNrRetries are give explicitly in call
In my case such a feature would have two benefits:
1a) Make it easy to quickly add a final field to a root base class,
without having to do some a major ctor refactoring on all the child
classes (for which I typically don't have the time, meaning that I am
forced to add the field as non-final "for now", so I can modify it after
object creation where needed).
Note that this can, even if IntelliJ would not sometimes not get the
refactoring wrong (which can lead to hard to track bugs), not be covered
by better refactoring support: Not having to give all the values for the
parameters before the newly added parameter (but instead having them
take their default value) is not something a refactoring engine can supply.
1b) Similar to 1a), for adding parameters to method calls
2) Make the calling of ctors/methods safer in certain cases
a) When a ctor/method takes a lot of parameters of the same type, e.g.
boolean: createPackageSql(String name, boolean trimQ, boolean
indentLinesQ, boolean keepEmptyLinesIndentationQ, boolean
seperateFunctionsQ, boolean uppercaseKeywordsQ, boolean uppercaseNamesQ)
{ ... } *
b) When a framework function is called by a framework user, e.g. from a
script, or generally in an environment where there is little or no test
coverage, and the paramter order can easily be confused: e.g. method
which retrieves a DB item through 2 IDs, and getting an empty result set
is not an error - which ID has to be given first ? Easy, when calling
with named paramters is supported pe.retrieveTreeNodeRow(orgUnit:123,
orgItem:456) .
mg
*Here a parameter object might be the better choice. But typically the
number of paramters was small at the beginning, and grew over time, so
initially no need for a paramater object existed. Again the refactoring
time needed to introduce a parameter object, the fact that your class
namespace gets cluttered with helper structures, external framework
users will have to adapt their code (or you must maintain a backward
compatibility facade), etc make this less practical than it might
initially seem...
