Skip to end of metadata
Go to start of metadata

This document is the report of our discussion during the second GroovyOne meeting.
You can even see a few pictures of the event that were posted to Flickr: tagged as jsr241.

Decisions

The main discussion was around name resolution and scoping rules.
The general idea which lead our discussions was to try to find rules which were as close as possible to Java, yet still allowing powerful and expressive features.

Write-up of the decisions

Icon

John Wilson contributed a thourough write-up of the decisions taken.

On resolution and shadowing

  • use metaclass for name resolution
  • variable names are able to shadow class names as in Java
  • class names and local variables are resolved at compile times

Changes to the Meta-Object Protocol with an improved MetaClass

  • We've agreed John Wilson's MOP proposition regarding MetaClass
  • We agree that the contract on MetaClass will change to support specific invokeMethod(), get/setProperty() with specific versions for this.* super.* (see John Wilson's proposition)
  • all calls/interception/property access should go through the MetaClass
  • tug proposed adding more information for groovy method calls, so that invocations can look at more type information of the parameters and the context within which it is present, thus improving dynamic invocation performance.
  • split metaClass proposal - have an interface which is part of groovy.lang.* which defines the public, committed MOP that folks can be dependent on - all the internal stuff for implementing the runtime/bytecode stuff are hidden in an internal org.groovy.runtime.* class
  • GroovyInterceptable should die (absolete anyway with the improved MetaClass)

Differences between Script and Class

  • scripts are 'open' by default, allowing dynamic properties
  • def will create a local variable not set on the property
  • use allows you to import what appear to be global functions etc

Multi methods

  • enable mult-methods by default to avoid suprises
  • very useful for equals() method....

More on multimethods

Other discussion topics not decided or postponed for 2.0

  • DSL support
  • break return continue in closures
  • C++ syntax for operator overloading

Coercion of interfaces with 1 method to a closure

This would be particularly interesting for frameworks like Spring using a lot of anonymous inner classes implementing some single method interfaces to behave similarly like closures.

Use

  • mixin and 'use' are different concepts
    • 1. I want some new groovy methods that I want to add to existing objects (a local view of object methods)
    • 2. I'm declaring class and I want to mixin methods
    • 3. Publically doing 1.
  • use now takes a static/lexical class name
  • can use 'use' at top of a file (probably after imports) and within a block.
  • the effect of use is to make a compilation-local ProxyMetaClassRegistry which has the used classes inside it so it can act as the provider of ProxyMetaClass instances used locally - only if the class really has been enhanced
  • at compile/IDE/shell typing time all classes have a static metaclass - after 'use' applied
  • a metaclass can be marked as being 'dynamic' meaning its open and can have any method or property at runtime - though most Java objects are 'closed' and static allowing smart completion & good error reporting.
  • in 1.0 we don't show the groovy syntax to define aspects etc - (e.g. DefaultGroovyMethods) - they are just available & people don't really need to know how to do them.
  • in 2.0 we will define Groovy syntax for writing the DefaultGroovyMethods (indeed we'll scrap DefaultGroovyMethods - and replace with real Groovy stuff)
  • 2.0 should consider adding use into a class delclaration, method decl, inside a class with field-ish scope

Brainstorming code snippets for use module support

XPath / XML

Some ideas on some brainstorming on XPath native support where GPath doesn't fit.

other

  • should this.println() be different from println()
  • you should not be able to call the following
  • decision to make: metaclass mutatation
    • valid mutations; some subset of things you can do like add methods etc
    • aGroovyObject.become(aMetaClass) or 'as', 'clone as', overload clone to take a metaclass...

Possible improvements to the MetaClass not yet designed

  • With MC#invokeConstructor() we could make the next sample work - but keep it inside the MetaClass implementation detail - hide from public MOP for now
  • give compiler a way to know about 'openness' (probably through the MetaClass); e.g. Map is open from a properties perspective; so is a JDBC RowSet; you may write an Expando thing which is open for any-old-method and any-old-property as well
  • Compile time we know the static structure of a class, and you can set an 'extensible' flag. Is it an 'open' type or closed type.
    • perhaps an introspection api on metaclass (action:tug)
  • maybe mark classes as dynamic if 'whacky stuff' is happening,
    (e.g. if overriding getProperty), this will give IDEs a hint

To be discussed for Groovy 1.0

  • what should be in or out from the RI

Funny quotes during the meeting

  • "Class files are immortal"
  • "Generics are evil!"
  • "We'll find a bar if there is one"
  • "def *"
  • No labels