commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject Re: [clazz] draft reflect implementation
Date Sun, 17 Nov 2002 22:49:13 GMT
I've finally had a chance to take a look at this. Its great work ;-)

Some questions:
- will it handle the case of defining
 int getAge()
 void setAge(String age)
 void setAge(int age)

- Can we handle related accessors, eg.
 int getAge()
 int getAgeAsString()
 void setAge(int age)
 void setAgeAsString(String age)

- Should ClazzProperty objects expose their read/write methods etc via
ClazzOperation/Operation objects?

- How do you actually do the plugin? I can see where to override, but I
can't see where to make the override happen.

One thing we do have to be careful of is not to make it too complicated. I'm
never sure exactly where that boundary is, and documentation always helps. I
also like lots of small packages, would reflect.list, and
reflect.scalar help?


----- Original Message -----
From: "Dmitri Plotnikov" <>
> I am not really done with the first draft yet, but since I will have to
> take about a week off from clazz, I wanted to commit what
> I have done so far and give you a chance to look it over.
> My initial focus was on implementing functionality equivalent to
> that of java.beans.Introspector. There are several pretty cool
> improvements over the Introspector:
> 1. Highly customizable design.
>     - You can add new ClazzLibraries for new kinds of Clazzes. So far
> there is only one such library, ReflectClazzLibrary, but more are
> coming.
>     - You can add new ClazzLoaders to customize Clazz generation for
> individual clazzes or groups of clazzes.
>     - In the case of Reflected clazzes, you can change the way accessor
> methods are bound to properties.  For example, if you want to make
> read methods look like "readFoo()" instead of "getFoo()", it is a matter
> of overriding one method on ReflectScalarPropertyIntrospector.
>     - In the case of Reflected clazzes, you can add new categories of
> properties.  The default list of categories consists of List (which
> works for Lists as well as arrays), Mapped and Scalar properties.
> 2. In the case of ReflectedClazzes, richer mapping of accessors to
> properties: methods like getFoo(int), setBar(key,value), getFooKeySet()
> etc are recognized.
> 3. If a property is Mapped, the corresponding clazzProperty.get()
> returns a Map, even if all the bean defines is a bunch of accessor
> methods like getFoo(key).  The Map implementation returned by
> clazzProperty will invoke those accessors if they exist (see the
> ReflectedMap).
> 4. Similarly, if a property is a List or an array, the corresponding
> value is a List (see ReflectedList).
> 5. Powerful diagnostic facility that optionally prints details of
> introspection.  You won't have to wonder any more: "how come it does
> not see my property 'foo'".  I have attached a sample diagnostic log.
> Check it out, it's pretty cool.
> The implemented functionality comes with tests, but as you will see not
> all functionality is implemented yet.
> Don't look for ATTRIBUTES, DELEGATORS or BEAN stuff yet - I'll get to
> that in a week or so.
> - Dmitri


> --
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message