groovy-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From MG <mg...@arscreat.com>
Subject Possible New Groovy Features...
Date Sun, 20 Aug 2017 20:25:53 GMT
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



Mime
View raw message