Go for it ;-) Stephen From: "Dmitri Plotnikov" <[EMAIL PROTECTED]> > I am ready to start implementing any piece nobody else wants. > > - Dmitri > > ----- Original Message ----- > From: "Stephen Colebourne" <[EMAIL PROTECTED]> > To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> > 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" <[EMAIL PROTECTED]> > > > 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" <[EMAIL PROTECTED]> > > > 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" <[EMAIL PROTECTED]> > > > 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>
