Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 63814 invoked from network); 28 Oct 2002 01:49:35 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 28 Oct 2002 01:49:35 -0000 Received: (qmail 4268 invoked by uid 97); 28 Oct 2002 01:50:32 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 4248 invoked by uid 97); 28 Oct 2002 01:50:31 -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 4234 invoked by uid 98); 28 Oct 2002 01:50:31 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Date: Sun, 27 Oct 2002 20:48:42 -0500 From: Dmitri Plotnikov Subject: Re: [clazz] Clazz API mock-up To: Jakarta Commons Developers List Message-id: <019101c27e24$2557f900$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: <008901c27dbd$91ca4b40$0200a8c0@GATEWAY> <3DBC8D41.3030904@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Berin, ----- Original Message ----- From: "Berin Loritsch" To: "Jakarta Commons Developers List" Sent: Sunday, October 27, 2002 8:05 PM Subject: Re: [clazz] Clazz API mock-up > Dmitri Plotnikov wrote: > > Please check out the two attached classes: Clazz and Field. These are client > > APIs only. Nothing is said about where the metadata is coming from - that's > > to come later. > > > > Here are some notes on the design of these two classes: > > > > 1. Clazz is a metadescription of a generalized bean (JDK bean, "modern" > > bean, DynaBean, Map, EJB etc). > > > > 2. In some cases there is more than one Clazz that can describe a particular > > object. For example, the same object can be described as a standard bean as > > well as a "modern" bean. Therefore I have introduced the notion of a > > "model" identified by a URI. I am thinking the URI itself might map to a > > verbal description of the model. > > > > 3. Clazz has a newInstance() method that is responsible for object > > allocation. > > I looked at the API stuff. I think there is an awful lot of extra stuff. > KISS (Keep It Simple, Stupid). I think the expression is actually "Keep It Simple and Stupid", otherwise it might sound like you are calling me stupid, which of course you never would. Do you really mean that there is an "awful" lot of extra stuff or you mean that the stuff is not very well compartmentalized into little Method objects? I'll buy that for a dollar. > Let's follow the java.lang.reflect.* as much as possible. Provide a > getClass() method to get the original class. Provide a getMethod() for > the AttributeMethod from the clazz. That sort of thing. Could you elaborate a little bit? Could you give some examples of APIs along with examples of how you envision them being used? I am especially interested in the dynamic case where there are no concrete classes, just data and metadata constructed at runtime. What would I use getClass() for? Why not call object.getClass() directly? What is the benefit of encapsulating access into a Method object? At this early stage of design work the reason has to be more than pure esthetics. - Dmitri -- To unsubscribe, e-mail: For additional commands, e-mail: