Message-ID: <1335143276.298252.1368909028100.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_298251_2093259490.1368909028100" ------=_Part_298251_2093259490.1368909028100 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
We need to improve the meta programming capabilities that Groovy offers.= This document outlines the future improvements proposed for the language.<= /p>
Currently it is unnecessarily hard to dynamically obtain and invoke over= loaded methods. I propose improvements to the MetaClass so given a class as= follows:
You can easily obtain and invoke the method as follows:
The way this would work is the MetaClass system would return a MethodPro= xy or some similar class that would contain references to all MetaMethods a= nd correctly dispatch to the right overloaded method
To avoid ambiguities this should also work with respondsTo
Currently it is harder than it needs to be to do per instance meta progr= amming in Groovy. ExpandoMetaClass currently applies to all instances and a= lthough you can do tricks to make a ExpandoMetaClass only apply to an insta= nce it is not clean.
I propose the ability to apply per instance methods by accessing the met= aClass of the instance. This would be consistent with our usage of the meta= Class on the java.lang.AClass. For example:
Achieving the above with Groovy objects will be trivial and just a matte= r of swapping out the meta class of the instance. For Java objects however = we will need a instance to MetaClass registry of some sort.
I think the whole ExpandoMetaClass.enableGlobally() thing needs to go an= d we need to make EMC (or the new implementation of EMC following the MOP c= hanges) the default
Maybe as per http://docs.codehaus.org/displa= y/GroovyJSR/Mixins
Or maybe something that is like Scala traits. Needs more discussion.------=_Part_298251_2093259490.1368909028100--