commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <>
Subject [clazz] Implementations
Date Wed, 30 Oct 2002 23:59:18 GMT
Ongoing implementation discussions between Dmitri and myself...

From: "Stephen Colebourne"
For the reflection case, they are basically wrappers of the Java classes:
 Clazz wraps Class
 ClazzProperty wraps Field
 ClazzOperation wraps Method
 Bean wraps Object
 Property wraps Object + Field
 Operation wraps Object + Method

From: "Dmitri Plotnikov" <>
> I am still just a tiny bit confused. Tell me again the names of the
> interfaces.

From: "Stephen Colebourne"
All 6 of the above are interfaces. My 'wraps xxx' description refers solely
to the reflection implementation. Thus the reflected class names would
probably be ReflectedBean, ReflectedProperty, ReflectedOperation.

From: "Dmitri Plotnikov" <>
> I agree with the logical associations in your list, but
> implementation-wise I think we need to do something more sophisticated
> than "wrap". For example, ClazzProperty is actually not necessarily a
> wrapper for a Field, but rather to all those accessor Methods and
> perhaps the Field too.  Is my understanding correct?

From: "Stephen Colebourne"
Actually it depends on the underlying bean. For most beans we should call
the get and set methods as you suggest, but for some others there is no
reason why not to access the Field object. Start with the standard case
though, which gives:
ClazzProperty wraps GetMethod, SetMethod and Field
Property wraps GetMethod, SetMethod and Field + Object

From: "Dmitri Plotnikov" <>
> Do I understand correctly that Bean is sort of a replacement for
> DynaBean?  Or is its purpose in life something else?  If it is like
> DynaBean, I am not sure why we need to wrap Field and Method and for
> that matter, which Field and Method we would wrap.  DynaBean simply be
> stores properties in a HashMap.  As far as Operations are concerned,
> DynaBean does not have any, but we can come up with something like a
> pluggable script ([jexl], Rhino, etc via BSF).  They would hang off the
> corresponding Clazz and would not require wrapping - just delegation.

From: "Stephen Colebourne"
Yes, Bean fulfills the same role as DynaBean. However you seem to describe
BasicDynaBean. Looking at [beanutils] DynaBean is the instance interface.
BasicDynaBean is the implementation of that interface using a Map. I suggest
that our implementation is called MappedBean.

For operations you are correct that a pluggable script or class will be
needed. At least for MappedBean. ReflectedBean can access the real methods
of the class. (The [pattern] Transformer interface could be used as the
plugin for MappedBean)


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

View raw message