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 Fri, 01 Nov 2002 12:31:25 GMT
Stephen,

I just don't want us working on the same pieces at the same time. Please let
me know if you are working on a particular piece to avoid that.

Thanks,

- Dmitri

----- Original Message -----
From: "Stephen Colebourne" <scolebourne@btopenworld.com>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Friday, November 01, 2002 4:05 AM
Subject: Re: [clazz] Implementations


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


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