I think ideas you proposed in BCEL list can be moved to this proposal too.
> Hi, > Currently, Betwixt and other users of BeanUtils rely on the java.beans class > Introspector to extract details from a class. Introspector is a very old and > limited class in todays terms: > - it doesn't support collections, just simple objects and arrays > - it doesn't support modern conventions such as addXxx() adds to a the xxx > list > - it doesn't support overloading well > - the bean info technique is difficult to code, poorly understood and > limiting > - it's just too plain dumb. > > I propose that BeanUtils/Betwixt/commons should replace Introspector with a > more general purpose reflection/introspection package. Architecturally this > would sit above reflection, but below Introspection: > > Requirements/Goals: > - handle classes other than beans > - support extensible metadata (not just for GUI builders) > - handle normal (today) bean conventions (get/set/add/put methods) > - handle future conventions that are not yet standard > - support method overloading > - be easily used directly from BeanUtils and Betwixt (and probably others) > - be a complete alternative to using java.lang.reflect > - return immutable objects > > My proposed solution (not coded, fully open to discussion): > Build a system with similarities to Digester. Rules get called when the > class is examined determine how to link the methods together. For example > the FindGetPropertyMethodRule would look at method names starting with get > etc. The rule then classifies the method as a GET method and stores it into > a structure something like this: > > - MethodSetInfo - holds details about a related set of methods. > public String getName() > public List getMethodInfos() > public MethodInfo getMethodInfo(name) > public Map getMetaData() > public MetaData getMetaData(String name) > > - ClassInfo - main class that holds the representation of class. Subclass of > MethodSetInfo > public List getMethodSetInfos() > public MethodSetInfo getMethodSetInfo(name) > public List getMethodSetInfos(methodSetType) > public MethodSetInfo getMethodSetInfo(methodSetType, name) > public PropertyInfo getPropertyInfo(name) // convenience > > - PropertyInfo - subclass of MethodSetInfo for properties (Lists/Maps etc. > tbd) > public Class getPropertyType() > public MethodInfo getGetMethodInfo() // convenience > public MethodInfo getSetMethodInfo() // convenience > public Object getValue() > public void setValue() > > - MethodInfo - categorised info about a method > public String getName() > public Method getMethod() > publc String getCategory() > public Map getMetaData() > public MetaData getMetaData(String name) > public Object invoke(object, args, respectAccessFlags) > > Attached to each element is the ability to hold MetaData. This is > particularly important for Betwixt. It would allow the XMLBeanInfo class to > be held directly on the representation of the class. And I'm sure other > projects want MetaData - its supposed to be a long standing request for J2SE > (I know I need it for the Joda project). > > Note that I haven't expanded on the Rule part at the moment. Basically, > people must be able to write their own rules and add them to the standard > rules for beans. > > As for which project it belongs with...I suggest lang or something new > (reflect?). I would like to extract it from BeanUtils because its not Bean > specific. > > > Well, its an idea at the moment. There are some similarities to DynaBeans, > but I think it goes way further. I already have a partial version of this, > but its specific to my needs. It needs some rework anyway, so I thought > about if it could be generic. Opinions?? > > Stephen > > PS. Three more possibilities for lang: > Nameable > MetaData > Rule > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
