Re: [BeanUtils][Betwixt][commons] Proposal: Reflection/Introspection/MetaData package

[Martin van den Bemt <ml...@mvdb.net>]

Looks like a perfect commons project then ;)

Mvgr,
Martin

On Sun, 2002-06-16 at 17:06, dion@multitask.com.au wrote:
> As does Velocity....I think it calls it UberIntrospector or something.....
> --
> dIon Gillard, Multitask Consulting
> Work:      http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
> 
> 
> 
> 
> Martin van den Bemt <ml...@mvdb.net>
> 06/17/02 12:19 AM
> Please respond to "Jakarta Commons Developers List"
> 
>  
>         To:     Jakarta Commons Developers List <co...@jakarta.apache.org>
>         cc: 
>         Subject:        Re: [BeanUtils][Betwixt][commons] Proposal: 
> Reflection/Introspection/MetaData package
> 
> 
> Also check this with the ant team, who have a lot of introspection in
> there code.. It works on all jdk versions afaik. 
> See o.a.tools.ant.Introspectionhelper.
> 
> +1 on the idea btw..
> 
> Mvgr,
> Martin
> 
> On Sun, 2002-06-16 at 13:40, Stephen Colebourne wrote:
> > 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:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> > 
> > 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>