[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: MutableClassInfo?

[stale.pedersen@jboss.org]

ok, after some days trying different approaches for the mutable design here is some of the first ideas (ive removed the javadoc to reduce the size of the code):
public interface MutableClassInfo extends ClassInfo
  | {
  |    
  |    MutableMethodInfo createMutableMethod(Body body);
  |    
  |    MutableMethodInfo createMutableMethod(ModifierInfo modifier, String name, 
  |          String[] parameters, String[] exceptions);
  |    
  |    MutableMethodInfo createMutableMethod(ModifierInfo modifier, String name, Body body, 
  |          String[] parameters, String[] exceptions);
  | 
  |    MutableMethodInfo createMutableMethod(ModifierInfo modifier, String name, 
  |          MutableClassInfo[] parameters, MutableClassInfo[] exceptions);
  |    
  |    MutableMethodInfo createMutableMethod(ModifierInfo modifier, String name, Body body,
  |          MutableClassInfo[] parameters, MutableClassInfo[] exceptions);
  | 
  |    
  |    MutableConstructorInfo createMutableConstructor(Body body);
  |    
  |    MutableConstructorInfo createMutableConstructor(ModifierInfo modifier, String[] parameters, 
  |          String[] exceptions);
  |    
  |    MutableConstructorInfo createMutableConstructor(ModifierInfo modifier, Body body,
  |          String[] parameters, String[] exceptions);
  |    
  |    void addMethod(MutableMethodInfo mmi);
  |    
  |    void removeMethod(MutableMethodInfo mmi);
  |    
  |    void addConstructor(MutableConstructorInfo mci);
  |    
  |    void removeConstructor(MutableConstructorInfo mci);
  |    
  | }

  | public interface MutableMethodInfo extends MethodInfo
  | {
  | 
  |    void setModifier(ModifierInfo mi);
  | 
  |    void setReturnType(String returnType);
  | 
  |    void setReturnType(MutableClassInfo returnType);
  | 
  |    void setName(String name);
  | 
  |    void setBody(Body body);
  | 
  |    void setParameters(String[] parameters);
  | 
  |    void setParameters(MutableClassInfo[] parameters);
  | 
  |    void setExceptions(String[] exceptions);
  |    
  |    void setExceptions(MutableClassInfo[] exceptions);
  |   
  |    /**
  |     * TODO: something similar to CtBehavior.instrument(...)
  |     * 
  |     * @param mmc
  |     */
  |    void executeCommand(MutableMethodInfoCommand mmc);
  | }

  | public interface MutableConstructorInfo extends ConstructorInfo
  | {
  | 
  |    void setModifier(ModifierInfo mi);
  |  
  |    void setBody(Body body);
  | 
  |    void setParameters(String[] parameters);
  | 
  |    void setParameters(MutableClassInfo[] parameters);
  | 
  |    void setExceptions(String[] exceptions);
  | 
  |    void setExceptions(MutableClassInfo[] exceptions);
  |  
  | }

  | public interface Body
  | {
  |    String getBody();
  | }
  | // There are three implementations of AbstractJavassistBody
  | // Default, InsertBefore, InsertAfter (to reflect javassist api)
  | public abstract class AbstractJavassistBody implements Body
  | {
  |    String body;
  | 
  |    AbstractJavassistBody(String body)
  |    {
  |       this.body = body;
  |    }
  |    public String getBody()
  |    {
  |       return body;
  |    }
  |    
  |    abstract void createBody(CtBehavior behaviour); 
  | }
The idea is that JavassistTypeInfo now will implement MutableClassInfo instead of ClassInfo. The usage of the Class parameter needs to be removed, internal methods using it will just use the CtClass object. The question is the method getType(), can we just remove it altogether? -its been marked as deprecated.

JavassistMethodInfo will implement MutableMethodInfo and JavassistConstructorInfo will implement MutableConstructorInfo the same way as JTI. Is there a reason why the JMI constructor is public? if not it should be set to package protected.

We need functionality to get the method signature from a method. This could be implemented in a utilclass, but i would rather see it added to the MethodInfo interface.
We might also need a method like ClassInfo.getClassLoader(), but i guess Kabir/Adrian know more about that.

I havent listed up any exceptions yet. There are a few exceptions, but they all extend RuntimeException so they are not listed. I have no big objections of having them extend Exception instead...

Design for fields will be posted later, but they will follow the same idea.
Javassist have a lot of functionality to create new methods/constructors/etc that i dont think we need to support directly in MCI, but rather create some util classes to do that. Im thinking of classes/methods like: CtNewMethod.copy/abstractMethod/getter/setter/delegator/etc.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4204378#4204378

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4204378