Skip to end of metadata
Comment: Migrated to Confluence 4.0
Go to start of metadata

Metadata

When

  • Brainstorming: May 11th-13th 2009
  • Code spikes: May 13th-15th 2009

Where

Paris, France

Participants

  • Brainstorming
    • Paul King
    • Dierk König
    • Guillaume Laforge
    • Peter Niederwieser
    • Jochen Theodorou
  • Code spikes
    • Paul King
    • Guillaume Laforge
    • Jochen Theodorou

Topics

The topics will range between the next coming versions of Groovy: namely Groovy 1.7 and Groovy 2.0. The main highlights will be the following:

Groovy 1.7

Groovy 2.0

  • Fate of JSR-241
  • Pattern matching (perhaps too much work to do before 1.7) — Guillaume Laforge
  • Discuss the design of a new Meta-Object Protocol
    • handling of access to private methods/fields/properties
    • general missing property/method handling (order of lookup, what extension points)
    • are invokeMethod and get/setProperty on GroovyObject still needed? What was their purpose in the first place and how did they develop?
    • How does EMC allow extension to invokeMethod and get/setProperty logics? (see for example http://groovy.codehaus.org/ExpandoMetaClass+-+GroovyObject+Methods) And should that be kept, or is it intelligent to do so?
    • How to isolate meta class registries? Is that a good thing, is it not needed? How does for example Ruby handle this?
    • How easily give any created and not yet created meta class a change? How to isolate such actions?
    • Having more information on call sites
    • more uniform method missing path
    • various scoping aspects
      • lexical or dynamic
      • block, class, package, OSGi
      • thread-bound or not
      • state tracing (stacked changes)
    • inheritance of meta-changes
    • fast
      • adaptable to invoke dynamic
      • avoid synchronization on data
      • relying on immutable data structures
      • change retrieval (transactionality?)
    • non leaking abstractions for the user
    • discovery of meta-changes
      • meta-inf/services
      • magic package
  • Some use cases
  • issues with 'private'

Notes

  • Mocking support is lacking and would need an overhaul in 1.7
  • Check for coverage support results validity
  • Discussion on extended annotations
    • Idea of encoding in the form of Strings: would create a script, which could support ranges, closures, regex. Try first with Strings to see how far we can go.
    • If such annotations can be reused from Java, what's up with parameter names, field access, etc?
    • Two aspects: adding annotations support on the various AST nodes, and how to encode that into bytecode
  • Regarding loosening the omission of parens, we've currently got a good compromise on readability
  • For Groovy 2.0
    • think about shipping some public stable AST interfaces on top of the concrete AST
    • allow the quoted identfiers for properties, fields, assignemnts
    • allow any character in classes fields, methods
    • fix closure naming for method names with spaces
    • Some ideas of what pattern matching could look like, without extending the Groovy grammar
  • Long discussions on the characteristics MOP2 should have
    • Illustrating advanced corner cases
  • AST Nodes to be made proper JavaBeans
  • Cleaning / review status of operator overloading
    • especially comparisons
  • GEP-2
    • phase, statementsOnly, etc, should be properties on the builder itself
    • properties on the Ast Builder itself
  • Modularity with Grapes
    • Status
      • Early discussion phase but leveraging existing concepts like grapes and  GROOVY-2116 (James Strachan's service registration proposal but enhanced)
      • Create a branch for playing with the concept and merge back onto 1_7_X/trunk at some point if successful
      • Nice to be able to enable some small bits before 1.7 beta but will depend on speed of creation followed by speed of feedback
    • Motivation
      • How to stop groovy-all jar from getting "too fat"
      • How to evolve GDK without breaking (or at least controlled breakage of) legacy scripts
      • How to better position Groovy for use in a wide range of scenarios (e.g. mobile)
      • How to allow Groovy ecosystem to blossom by allowing many grapes to be created  but without requiring all of them to be bundled
    • Proposed changes visible to users
      • leverage grape system even for Groovy's GDK (may involve "bundled grapes")
      • enhance GroovyStarter/LoaderConfiguration to support --grab on commandline and grab in conf file (see also GROOVY-3215 conf file in Groovy)
      • (slightly orthogonal but related change) enhance AST transform support to allow scripts to grab without need for a class or method definition, e.g. "@grab(...) Script" (or replace Script with "this" or something else)
      • non-all jar will be much slimmer but conf file will download other jars or at least use other jars in distribution zip
      • service registration (GROOVY-2116) but enhanced. Each grape can have a META-INF/services/groovy directory with one or more of the following files  
        • groovyMethods - list of class files containing normal category methods  to be registered at global level
        • groovyStaticMethods - list of class files containing static category methods to be registered at global level
        • groovyExpandoMethods - list of class files containing expando defns
        • groovyAstTransforms - ?? but only transforms that come after grape phase?
        • groovyBuilderMetadata - ?? of help to IDEs, e.g. AntBuilder/SwingBuilder
        • auto import registration
        • runner registration (e.g. easyb runner like testng runner)
      • existing grapes can be changed to better handle "service registration"
      • gdk (or pieces) will start to have version numbers (how to relate  version numbers with corresponding runtime versions?)
    • Proposed changes invisible to users
      • all-jar will come bundled with (almost?) all current functionality (opportunity to remove deprecated functionality?)
      • minor changes to current source structure (but do we move to almost like separate 'modules' and move tests)
      • minor changes to build files
    • Points to consider
      • which parts of GDK to tackle All? All but core? Just some less used parts to start with? Tools?
      • granularity of grapes
        • "@grab xml" vs "@grab xml.slurper and @grab xml.parser"
        • "@grab jmx" vs "@grab jmx.builder"
        • names to use? ivy/maven/OSGi
        • versioning scheme to use
      • potential grapes:
        core?, numbers?, strings? bsf, jsr223, sql, xml, jmx, time, date, collections, cli, maps, file, streams, process, threads, templates, regex?, encoding, ant, newify?, googleCollections, jsr203/nio, jodatime, actors, combinators, BigTable?, Scala compiler hooks/Scalify
      • format of META-INF/services file: list of classes or groovy file
      • graceful degradation: jars, poms, OSGi manifest, META-INF/services
      • think through implications for various embedded usages of Groovy
Labels
  • None