commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephen Colebourne" <scolebou...@btopenworld.com>
Subject Re: [clazz] Implementations
Date Fri, 01 Nov 2002 09:05:10 GMT
Go for it ;-)
Stephen

From: "Dmitri Plotnikov" <dmitri@apache.org>
> 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>
>


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