Re: [clazz] Implementations

[Stephen Colebourne <sc...@btopenworld.com>]

Go for it ;-)
Stephen

From: "Dmitri Plotnikov" <dm...@apache.org>
> I am ready to start implementing any piece nobody else wants.
>
> - Dmitri
>
> ----- Original Message -----
> From: "Stephen Colebourne" <sc...@btopenworld.com>
> To: "Jakarta Commons Developers List" <co...@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" <dp...@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" <dp...@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" <dp...@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:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
> >
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [clazz] Implementations

[Dmitri Plotnikov <dm...@apache.org>]

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" <sc...@btopenworld.com>
To: "Jakarta Commons Developers List" <co...@jakarta.apache.org>
Sent: Friday, November 01, 2002 4:05 AM
Subject: Re: [clazz] Implementations


> Go for it ;-)
> Stephen
>
> From: "Dmitri Plotnikov" <dm...@apache.org>
> > I am ready to start implementing any piece nobody else wants.
> >
> > - Dmitri
> >
> > ----- Original Message -----
> > From: "Stephen Colebourne" <sc...@btopenworld.com>
> > To: "Jakarta Commons Developers List" <co...@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" <dp...@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" <dp...@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" <dp...@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:
> > <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> > >
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> <ma...@jakarta.apache.org>
> >
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>