Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 36773 invoked from network); 1 Nov 2002 12:31:58 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Nov 2002 12:31:58 -0000 Received: (qmail 22387 invoked by uid 97); 1 Nov 2002 12:32:47 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 22371 invoked by uid 97); 1 Nov 2002 12:32:47 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 22359 invoked by uid 98); 1 Nov 2002 12:32:46 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Fri, 01 Nov 2002 07:31:25 -0500 From: Dmitri Plotnikov Subject: Re: [clazz] Implementations To: Jakarta Commons Developers List Message-id: <06d701c281a2$98359a50$0200a8c0@GATEWAY> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Mailer: Microsoft Outlook Express 6.00.2720.3000 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20021030230012.3056.qmail@web11703.mail.yahoo.com> <012f01c28070$5d1d77e0$fd4229d9@oemcomputer> <066601c28077$bfcc5c60$0200a8c0@GATEWAY> <004601c28185$c83bf040$412729d9@oemcomputer> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N 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" To: "Jakarta Commons Developers List" Sent: Friday, November 01, 2002 4:05 AM Subject: Re: [clazz] Implementations > Go for it ;-) > Stephen > > From: "Dmitri Plotnikov" > > I am ready to start implementing any piece nobody else wants. > > > > - Dmitri > > > > ----- Original Message ----- > > From: "Stephen Colebourne" > > To: "Jakarta Commons Developers List" > > 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" > > > > 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" > > > > 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" > > > > 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: > > > > > For additional commands, e-mail: > > > > > > > > > > > > > > > > > -- > > To unsubscribe, e-mail: > > > For additional commands, e-mail: > > > > > > -- > To unsubscribe, e-mail: > For additional commands, e-mail: > > > -- To unsubscribe, e-mail: For additional commands, e-mail: