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>
