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 »

A small collection of ideas for MOP 2

ideas by Jochen:

  • we should no longer directly invoke methods like equals, setProperty and such.(see GROOVY-2635 for example)
  • we should think about changing GroovyObject into a pure marker interface (if setProperty is needed in the logic we have problems)
  • the MetaClass should be able to overwrite all methods including setProperty (this implies that we do not directly call setProperty)
  • Comparable needs a rethought. This interface is not well to be used if you have to handle objects of different types
  • it would be nice to be able to define only one operand like < or > instead of having to define both. At last being able to define these additionally
  • we have to test if creating direct method call classes in call sites is doable. This would be like Reflector, but only for a single method, allowing the JIT to inline the method without much hazzle. currently reflection means to have a border where the JIT can not really inline the call. Maybe we should also have different modes here, to allow users to still use reflection if this version has a problem on certain VMs or in certain scenarios
  • as a design goal I would like to transform the MetaClass from a directly method invoking to a request oriented method returning class. This would be especially interesting for call site caching. The user could still write his invokeMethod method, but instead of calling that method directly in the Metaclass we would let the MetaClass return a method wrapper that can do the call to invokeMethod.
  • I would also like to add a Listener to each MetaClass which allows other parts of the program to be informed when a MetaClass is changed in any kind. This could probably also be used to invalidate call site caches.
  • A version information added to the MetaClass allows a very fast check for changes. We could also think about adding an additional version cache for method names. the idea here is to have a simple array and to let a call site cache the index to the array, which means the index is equal to a complete method signature or only to name. By checking the information in there(for example an referential identity check with the cached method) would allow the call site to quickly know if it needs to update or not. Such an array would grow other time if it needs to reflect dynamically added methods as well. So we should do this maybe only for the default methods.
  • another design goal should be that if a code modifies a Metaclass, then as much changes as possible should be done by the thread modifying the metaclass. that means that this thread will for example call all the listeners, probably update caches, reorganize structures.. what ever
  • The allow call sites faster access without going through the registry it would be good to have some kind of handle that can be used to directly access the MetaClass. This means that either the real MetaClass must not be replaced (only on the implementation side of course) or that the handle is update if a replacement happens.
  • I would also like to add a module concept based on different meta class registries. For this a class using a module will contain some kind of information that will cause all code directly in this class to use only the meta classes from the registry and probably no per instance meta class. As some kind of namespace is required to differentiate one module from another we could couple this with the package "package foo with module" or by using a package like reference to a constant "module Foo.myRegistry" (Foo is a normal class, myRegistry is a final (question) public static field of type MetaClassRegistry or an alibi type. Annotations seem not to be fitted for this, as they would have to use enums, classes, primitives or strings and none but strings seem to fit that. enums won't work as I would have to define all possibilities in the runtime not allowing the user to define his own ideas of how it should work. Using classes would work, but where is the connection here to make it clear what we mean? primitives lack memorization, the user would have not only to remember a number, he would also have to make sure that it is not used somewhere else too. Strings are better, but there might still a name conflict. An Annotation would be doable if we want to make the module per class, but I am not sure this makes much sense.
  • we should also look if we can not reduce the amount of MOP methods. We need one for each non public method, true, but we possibly do not need all these super$ methods
  • as Java still does direct calls we should think about adding the ability to methods to check if their MetaClass has a new version for this method. This way Java could easily access the meta class stored method. Of course we then have to also find a way to access the original method as well, as this method may be needed
  • we should also think if we should add mechanisms we add for method calls should also be added for property access.
  • we need to look at method caching in builders.... or maybe this is not needed as a builder might not be executed often
  • for the meta class implementation we should also think about having special method selectors like I have in ClosureMetaClass.
  • if we do call site caching, then we should probably remove the method caching inside the MetaClass, especially if we add specialized method selectors
  • a point of discussion is if a method added to the parent classes metaclass should also affect the current metaclass or not.
  • we need also to test if rewriting the method itself at runtime is possible and what it will cost.
  • we need to investigate if inlining primitive type operations at compile time is possible. This can help avoiding boxing and direct usage of primitive types. Of course before doing something like that we would have to check the Metaclasses and all operations if this is allowed. If we do the idea with the method signature arrays we could also define constants for certain operations like +,-,*,/ to do the check very fast. If I do for example 1+1 I could compile this as: "if (Integer.metaclass.version==0 && Integer.metaclass.ops1==0) {iload 1; iload 1; iadd;}" 0 would show it is the default version and 1 is a numeric constant to see if the operation + is still the default or not.
  • maybe the module concept can be used to enable calling private methods/fields. With this we could disable access to private from outside the class per default.. of course onlny after we solved the Closure problem (information loss with getProperty)
  • invokeMethod should loose its double role for being a method missing and at the same time a direct invocation way from Java
  • No labels