commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ola Berg <ola.b...@arkitema.se>
Subject Re: [reflect] Proposal: (WAS [BeanUtils] etc...)
Date Sun, 16 Jun 2002 18:52:20 GMT
>The multitude of potential users of this component is 
>huge, they all have
>current solutions and they all have some peculiarities about them.  For this
>new component to be successful, we will need to address all of those
>requirements, which calls for an abstract, configurable and customizable
>architecture.

I don\'t agree. Well, of course there are many users that do a lot of stuff in their reflection/introspection
packages.

But IMO reflect should be a mere utility for easy use of reflection (reducing complexity and
awkwardness in java.lang.reflect). Other cool things (like automatic configuration of beans
from command line or config files) do belong in other packages (both examples above should
go in a Configuration framework?).

Those are _users_ of reflection, they don\'t faciliate reflection in themselves. This doesn\'t
call for plugable architectures, and if we end up with it I believe that we have over-engineered
them and missed a clean separation of concerns.

I think of a Reflection class with static methods like 

Reflection.set( Object bean, String propertyName, Object value);

Object o = Reflection.get( Object bean, String propertyName); 

Reflection.add( Object bean, String propertyName, Object value);

Reflection.put( Object bean, String propertyName, Object key, Object value);

Reflection.set( Object bean, String propertyName, int index, Object value);

Object result = Reflection.call( Object bean, String methodName, Object [] parameterValues);

The internals of a Reflection class could very well use a plugable framework for insertion
of new handy methods and cached lookup of reflection Method objects (like all getters in a
class etc), and some of this functionality should probably be pluggable (for people to insert
new bean-like naming conventions, maybe using Predicate on methods).

But main functionality exposed as handy methods.

/O

--------------------
ola.berg@arkitema.se
0733 - 99 99 17

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message