[groovy-dev] Re: Annotation closures available in trunk

Peter Niederwieser wrote:
> 
>> This AST xform generates an inner class for the first prop, it casts the
>> closure to a PropertyChangeListener on the second case.
> I'd be cautious about the second case; it seems to be turning invalid into
> valid Groovy code, which will likely break tools (IDEs in particular) and
> joint compilation.
> 

Actually the code is roughly equivalent to this

import griffon.util.Listener
import groovy.beans.Bindable

class MyModel {
     <at> Bindable
    String name

     <at> Bindable
    String value

    def myListener = { ... }

    MyModel() {
        addPropertyChangeListener('name', new PropertyChangeListener() {
           void propertyChange(PropertyChangeEvent evt) {
               contrtoller.someAction(evt)
           }
        })
        addPropertyChangeListener('value', myListener as
PropertyChangeListener)
    }
} 

So as long as the 'myListener' property has a closure value that takes a
single param we're covered (the AST xform does check the value to be a
closure but not the # of args)

Peter Niederwieser wrote:
> 
> AST transforms playing their own games with annotation closures should be
> fine because groovyc won't touch the closures until phase class
> generation. Ideally, transforms would keep replacing the closure with a
> class literal to prevent generation of another inner class.
> 

Then again, as long as my own AST xforms can translate the closure value to
something else, not just a class literal then there won't be any clash. My
concern is this new feature getting a hold of the closure values before my
own AST xform can process it.
--

-- 
View this message in context: http://groovy.329449.n5.nabble.com/Annotation-closures-available-in-trunk-tp512450p512545.html
Sent from the groovy - dev mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email