MetaClass Redesign (by blackdrag) part 2

...

package groovy.lang;   public

public interface MetaClass { 
  // MOP  MOP
  void addMOP(MetaClassObjectProtocoll mop);
  MetaClassObjectProtokoll removeMOP(MetaClassObjectProtokoll mop); 

  // add methods and  properties properties
  void addMethod(MetaMethod mm);
  void addProperty(MetaProperty mp); 
  void addConstructor(MetaMethod mc); 

  // listener for MetaClass changes changes
  void addMetClassListener(MetaClassListener mcl);
  void removeMetaClassListener(MetaClassListener mcl); 
  MetaClassListener[] getMetClassListeners(); 
} 

 So So the central point is addMOP, which allows to customize the method invocation for example. Besides this there are some methods for mutating the MetaClass (adding properties and such), a standard listener interface that allows to react to additions of properties for example. The implementation of this is not relevant for the user as it is thought as specification. The implementation depends on the Grovy runtime and might differ from other runtimes if there are ever such runtimes.

...

//old
coderegistry.setMetaClass(theClass,myMetaClass) 
// new code metaClasscode
metaClass = registry.getMetaClass(theClass)metaClass.addBehavior(myMOP)
// or in one line registryline
registry.getMetaClass(theClass).addMOP(myMOP)

 So So the one-line codebecomes a more complex two-line code, unless we decide to change MetaClassRegistry to make that by itself.

...

 The old code was like this:

 groovyObjectgroovyObject.metaClass = myMetaClass

 The The new code will look like this:

 groovyObjectgroovyObject.metaClass.addMOP(myMOP)

 So So the change here is minimal. The code to create a per instance MetaClass is hidden by the implementation and might differ. This of course means that the class GroovyObjectSupport, which is part of groovy.lang has implementation knowledge inside. So a implementator must change this class to his version of the runtime.

...