[reflect] Some thoughts

[Ola Berg <ol...@arkitema.se>]

In my reflect packet I have the classes Getters, Setters, Adders,
Putters and Constructors and Call and Methods. Setters.set( Object
bean, \"property\", Object value) sets the value on a property etc.
There are also methods for retrieving the type (as a Class) for a
given property, getting all settable properties etc. Mutatis mutandis
for putters, adders and getters.

Inside I have a lookup mechanism based on two Maps: One static
(JVM-singleton) that maps Class to Setters.Info (one Setters.Info
object for each looked up class). Each Setters.Info object has a map
that maps the propertyName to Method object for the corresponding
setMethod(). If the Object bean isn\'t looked up, the Setters class
will look it up. Any possible overhead for reflection is thus reduced
to two lookups in hashtables.

The thing I have found is that Getters, Setters, Putters etc shares
many common mechanisms. Basically, the lookup in each class iterates
through the methods, looking for a method of a certain pattern
(public void setXxx( type)). Which means that one could do a generic
base class for Setters/Getters etc, only providing different
Predicates (that operates on Method objects).

I think I start write some example code tonight and put it on my
webspace. Question is: when one should do such example code, should
one do it as a org.apache.commons.reflect package, or should I provide
a nu.viggo.reflect package? Or does it matter at this stage? (never
been into apache developement before so I don\'t know how you do it).

/O

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

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

Re: [reflect] Some thoughts

[Stephen Colebourne <sc...@btopenworld.com>]

From: "Ola Berg" <ol...@arkitema.se>
> In my reflect packet I have the classes Getters, Setters, Adders,
> Putters and Constructors and Call and Methods. Setters.set( Object
> bean, \"property\", Object value) sets the value on a property etc.
> There are also methods for retrieving the type (as a Class) for a
> given property, getting all settable properties etc. Mutatis mutandis
> for putters, adders and getters.

I was thinking of an interface that can recognise these different types of
method, without necessarily needing to have separate classes for each type.
But that is open for discussion.

> Inside I have a lookup mechanism based on two Maps: One static
> (JVM-singleton) that maps Class to Setters.Info (one Setters.Info
> object for each looked up class). Each Setters.Info object has a map
> that maps the propertyName to Method object for the corresponding
> setMethod(). If the Object bean isn\'t looked up, the Setters class
> will look it up. Any possible overhead for reflection is thus reduced
> to two lookups in hashtables.

Caching will be important. I just optimized an app where reflection was a
major part of the problem.

> The thing I have found is that Getters, Setters, Putters etc shares
> many common mechanisms. Basically, the lookup in each class iterates
> through the methods, looking for a method of a certain pattern
> (public void setXxx( type)). Which means that one could do a generic
> base class for Setters/Getters etc, only providing different
> Predicates (that operates on Method objects).

My feeling is that the Rule part is going to be more complex than a
Predicate, but equally I don't want it to be too complex!

> I think I start write some example code tonight and put it on my
> webspace. Question is: when one should do such example code, should
> one do it as a org.apache.commons.reflect package, or should I provide
> a nu.viggo.reflect package? Or does it matter at this stage? (never
> been into apache developement before so I don\'t know how you do it).

If writing code helps you to determine your requirements then fine (and the
package doesn't matter). The main thing at first will be getting the
requirements down from the various sources.

Stephen




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