Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@apache.org Received: (qmail 16107 invoked from network); 18 Nov 2002 22:53:59 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 18 Nov 2002 22:53:59 -0000 Received: (qmail 6333 invoked by uid 97); 18 Nov 2002 22:55:02 -0000 Delivered-To: qmlist-jakarta-archive-commons-dev@jakarta.apache.org Received: (qmail 6317 invoked by uid 97); 18 Nov 2002 22:55:01 -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 6305 invoked by uid 98); 18 Nov 2002 22:55:01 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) Message-ID: <008501c28f55$759fe340$5a0f29d9@oemcomputer> From: "Stephen Colebourne" To: "Jakarta Commons Developers List" , References: <20021118172210.26165.qmail@web11703.mail.yahoo.com> Subject: Re: [clazz] draft reflect implementation Date: Mon, 18 Nov 2002 22:54:32 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Dmitri Plotnikov" > > - will it handle the case of defining > > int getAge() > > void setAge(String age) > > void setAge(int age) > Currently it will reject this property altogether as having to > accessors. What should it do? And generally speaking, how do we > justify our choices in how methods are mapped to properties? Do you > think we have the authority to introduce some kind of a "standard"? > Taking into account the customizability of clazz, I believe we might. > Thus, why not simply decide what we are going to do by default in all > these cases by voting? For example, in the above case we probably have > three reasonable solutions: > > 1. Reject the methods as conflicting > 2. Accept the setAge(int) method as the getter and ignore > setAge(String) > 3. Accept them both and decide dynamically which one to call based on > the type (and perhaps converability) of the value. We may have to have an java Introspector compatable mode, to enable [clazz] to plugin to projects currently using the Introspector. However, lets concentrate on the sensible approach moving forward at the moment. If we can get to having a Property with a primary readMethod plus a list of secondaries, then #3 above becomes possible. Stephen -- To unsubscribe, e-mail: For additional commands, e-mail: