commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dmitri Plotnikov <dmi...@apache.org>
Subject Re: [clazz] Implementations
Date Thu, 31 Oct 2002 00:52:05 GMT
Got it. Thanks.

I am ready to start implementing any piece nobody else wants.

- Dmitri

----- Original Message -----
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Wednesday, October 30, 2002 6:59 PM
Subject: [clazz] Implementations


> 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" <dplotnik@yahoo.com>
> > 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" <dplotnik@yahoo.com>
> > 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" <dplotnik@yahoo.com>
> > 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)
>
> Stephen
>
>
>
> --
> To unsubscribe, e-mail:
<mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
<mailto:commons-dev-help@jakarta.apache.org>
>
>
>


--
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