Groovy DevCon 7

Metadata

Topics

• possible syntax alignments for the new grammar
• decide if to make the new MOP for Groovy3, or only the grammar
• more indy enhancements in final, 2.1?
• compatibility layer for things like ArrayUtil, old power asserts
  
  • using modules for that to keep the old classes around
• "true" named parameters
• traits
• stream / lazy / for comprehensions / generators 
  
  • ex from Tim, http://blog.bloidonia.com/post/22117894718/groovy-stream-a-lazy-generator-and-list-comprehension
  • also check what's happening in JDK 8's lambdas with regards to the lazy collection API additions
• joint compilation with the Groovy Eclipse compiler
  
  • also problem of reflection usage which seems to impact Gradle users
• pattern matching
• how to better engage the community so as to get more contributions and more active contributors
  
  • for ex. some kind of bug parade with low-hanging fruits for people to get a foot in the project
• documentation / specification discussion
• \@DelegatesTo to define closure delegates (nice for code completion and static analysis) GROOVY-5455
• further modularity steps
• static type checking improvements with regards to closure parameter type information
• changes and/or additions regarding curry / curried
  
  • see mailing-list dicussion

Discussions

• Peter's points for Gradle
  
  • Joint compilation (7 points)
    
    • groovyc creates ClassNode from Java source
  • Compile class path (4 points)
    
    • groovyc creates ClassNode from bytecode (without classloader)
  • Some backwards compatibility (2 points)
    
    • tester and guaranteed
    • super MOP methods should not user number scheme
    • when runtime classes are moved, keep a delegate in old location
  • Add @DelegatesTo annotation (10 points)
    
    • nothing else to do!

• Add @DelegatesTo annotation
  
  • check with Andrew
  • nice way to help IDEs
  • helpful for documentation
  • could be used from static type checking
  • could support the delegation strategy through a parameter
  • bring on the list
    
    • in which package?
    • in which version(s)? (2.0.1?)
• Joint compilation
  
  • need a (partial) java grammar up-to-date
    
    • no need for a full one, just for structure and performance
  • import resolution issue
    
    •  java and groovy resolution different
    • means we also need a CompileUnit (ie. containing the imports)
    • a different import type resolution based on the language (ie. java or/and groovy)
  • experiment in a module
  • target 2.1+
    
    • and probably not 1.8
• Compile classpath
  
  • may help with compilation speed (ie performance)
  • groovyc creates ClassNode from bytecode (without classloader)
  • use ASM to parse the bytecode
  • might solve problems with API JARs like servlet / java-ee where methods don't have a body
  • don't have to load dependencies defined in private fields and methods (example: Spring, Spock-Spring...)
  • target 2.1+
• Investigate encoding class names in the numbering scheme of super bridge methods
  
  • but breaks backward-compability already as no Groovy 1.8 and 2.0 programs wouldn't work at all!!!
  • more something for Groovy 3
  • reducing the number of bridge methods we generate
  • investigate if static method calls can be made instead of the dynamic ones
  • currently, not possible for @CompileStatic to not generate all those bridge super$ methods

• GroovyDoc issues
  
  • inherits tag not supported
  • old skin
  • @Documented not supported
  • shouldn't use reflection
  • perhaps there's a doclet approach to javadoc to understand groovy's javadoc comments
  • keep track of the module we're in

• named parameters
  
  • 3 possible implementations in Java 
    
    • class attributes
      
      • only available in JDK 8
      • perhaps not available through reflection, so not usable from Groovy
    • runtime annotation
      
      • accessible from Groovy
      • use a class from JDK 8
        
        • means need for a backport for earlier VMs
    • class file visibility (ie not source, not runtime)
      
      • not be able through reflection
        
        • unusable from Groovy
  • we can only have a partial solution, if it's runtime annotation
  • link to the JEP: http://openjdk.java.net/jeps/118
  • problems of supporting our "own" named parameters and JDK 8 if ever it gets supported
  • tricky cases like def foo(Map x, int i) called with foo(i: 1, 0)
  • considering it may be in JDK 8 in september 2013 (or probably much later!), we could integrate Peter's implementation?
    
    • perhaps worth a GEP
    • especially investigate the corner cases

• generators / for comprehensions / continuation-passing /  etc brainstorming
  • also see Tim's stream: http://blog.bloidonia.com/post/22117894718/groovy-stream-a-lazy-generator-class-for-groovy
  • but wait for JDK 8 new lazy stuff to mature to avoid reinventing the wheel or having two different implementations and notations for the same thing
  • but we can play with some experimental extension module

// closure list
( print "hi" ; def s = 23 ; println s )

list.each(def sum = 0;){}
list.each { 
    @Xyz sum = 0 
    sum += 1
}

// using some annotation?
list.each @Sum({}) { }
list.each { @Xyz sum = 0, elem -> sum += elem }

for (int i = 0; i < 10; i++) { ... }

// for comprehension
{ x | x in 1..3 && x % 2 == 3 }

// some iterator transformation
def fib = [
 state: [a: 0, b: 1],
 next: {
    state.a
}, hasNext: {
    (state.a, state.b) = [state.b, state.a + state.b]
    true
}] as Iterator

// python generator
 def fib():             
    a, b = 0, 1             
    while 1:                 
        yield b                 
        a, b = b, a+b

// again with some annotation
def fib = { @Xyz a = 0, @Xyz b = 1 -> 
    (a, b) = [b, a + b] 
    return a
}