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 4 Current »

In MetaClass Redesign (by blackdrag) I tried to show some ideas of how such a redisgn might look like and what the advantages and disadvantages might be.


In this part I want to show a more detailed version of one idea. that is a implementation based MetaClass is in front and the user can add custom behaviors. This limits the basic MetaClass interface to mere adminisatrative methods

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.

Usage of groovy.lang.MetaClass

If the user wants to influence themethod invocation process for example, then he has to implement the MetaClassObjectProtokoll interface, which I will show later. In this section I want to show how to create a per instance MetaClass and how to use it.

 changing a MetaClass in the registry

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

 creating and changing a per instance MetaClass

 The old code was like this:

The new code will look like this:

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.

 Using the Listener to MetaClass changes

(add interface)



  • No labels