Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »


We need to improve the meta programming capabilities that Groovy offers. This document outlines the future improvements proposed for the language.

Easy overloaded method invocation

Currently it is unnecessarily hard to dynamically obtain and invoke overloaded 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 MethodProxy or some similar class that would contain references to all MetaMethods and correctly dispatch to the right overloaded method

To avoid ambiguities this should also work with respondsTo

Easier Per instance Meta programming

Currently it is harder than it needs to be to do per instance meta programming in Groovy. ExpandoMetaClass currently applies to all instances and although you can do tricks to make a ExpandoMetaClass only apply to an instance it is not clean.

I propose the ability to apply per instance methods by accessing the metaClass of the instance. This would be consistent with our usage of the metaClass on the java.lang.AClass. For example:

Achieving the above with Groovy objects will be trivial and just a matter of swapping out the meta class of the instance. For Java objects however we will need a instance to MetaClass registry of some sort.

Make the default MetaClass an ExpandoMetaClass

I think the whole ExpandoMetaClass.enableGlobally() thing needs to go and we need to make EMC (or the new implementation of EMC following the MOP changes) the default

Add support for class level and instance level Mixins

Maybe as per

Or maybe something that is like Scala traits. Needs more discussion.

  • No labels