Skip to end of metadata
Go to start of metadata

Metadata

When

June 6th (afternoon) and 7th (full day) 2012

Where

Copenhagen, Denmark

http://kulturogfritid.kk.dk/kulturhuset-islands-brygge

Participants

  • Guillaume Laforge
  • Jochen Theodorou
  • Cédric Champeau
  • Peter Niederwieser

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 
  • 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
// 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
} 
A Groovy 1.8 compatible fib generator

 

  • Contributions
    • Groovy module contributions
      • how to share and reuse contributed modules easily
      • discuss with the Grails team to see how they're handling their plugins portal
        • and see how Andres is handling that within Griffon
        • Gradle is also interested in some Gradle plugins portal
        • is there some common base or collaboration possible that would suit everybody?
      • things to consider
        • a module should be one @Grab away
          • somehow uploaded to Maven Central?
          • is there a way to reuse the Groovy Modules Codehaus project
        • perhaps some modules can be part of the distribution
          • but if yes, what are the criteria
        • how to assert that modules work with various Groovy versions
          • and how to ensure that a new Groovy version doesn't break modules
          • some CI solution?
        • how to deal with sources? github vs codehaus groovy modules repo
        • nice gradle template build that would care of the uploading to Codehaus Groovy Modules
          • that could also test with various groovy versions
          • contributors can have their repositories anywhere
    • Random ideas
      • bug parade with "low hanging fruits" JIRA issues
      • award tshirts for the best contributions, most active contributors, etc
    • How to involve companies to contribute employees time to the project

 

  • modularity status
    • might be nice to have file extensions
      • check for projects like Griffon / Easyb and others if they'd find it useful
      • nice for static compilation (no need for @CompileStatic 
    • but for other further improvements, wait for feedback and see how people are using extension modules
    • mark what's been done from the GEP vs what's remaining or can potentially be considered for further enhancements

 

  • static type checking improvements with regards to closure parameter type information
    • wait and see for the feedback of users on static type checking before investigating further

 

  • changes and/or additions regarding curry / curried
    • see mailing-list dicussion
    • could be experimented in a contribution module

 

  • Random tasks
    • check if 1.7 compiled code runs on 2.0 runtime
      • to see if we'd need to support old power assert package for a potential compatibility module
    • check the binary snapshot of bnd
      • to see if that works fine for the indy build
    • investigate what traits could be looking like in Groovy
      • compared to @Delegate
      • see what other languages are doing
      • state vs no state
      • how to deal with super and this
      • what happens with overloading / method with same signatures
    • formalize some module contribution solution (GEP?)
    • formalize traits (GEP?)
    • formalize pattern matching (GEP?)
    • finish the specification tool and start writing some initial specification documents

 

 

  • Roadmap
    • 2.0.1
      • small bug fixes and critical bug fixes
    • 2.1
      • new features (not backported to 2.0.x)
      • new invoke dynamic improvements (because of bytecode compatibility)
    • 2.x
      • modularity: file extension support
      • compiler should support warnings, especially deprecation warnings
    • 3.0
      • big new features, potentially breaking
      • MOP 2
      • get rid of ArrayUtil
      • get rid of timestamp in compiled classes
        • removing reloading in GCL
    • 4.0
      • Grammar / Antlr 4
Labels
  • None