Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 17094 invoked from network); 29 Jan 2002 23:07:17 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Jan 2002 23:07:17 -0000 Received: (qmail 20997 invoked by uid 97); 29 Jan 2002 23:07:20 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 20953 invoked by uid 97); 29 Jan 2002 23:07:19 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 20941 invoked from network); 29 Jan 2002 23:07:19 -0000 Message-ID: <005f01c1a918$eb7f9200$0100a8c0@jose> From: "Jose Alberto Fernandez" To: "Ant Developers List" References: Subject: Re: [IDEA] Polymorphic types Date: Tue, 29 Jan 2002 23:01:42 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Can you give an example of your proposal? I really do not understand how it works. Jose Alberto ----- Original Message -----=20 From: "Tim Dawson" To: Sent: Tuesday, January 29, 2002 8:12 PM Subject: Re: [IDEA] Polymorphic types I like the idea of polymorphic types, but I'm not sure about this type = of implementation - it requires that the type be a subclass of another = type, and would prohibit interface implementation from working. When I = first ran into a similar issue a while back I got to thinking that what = would be a better approach would be to pair this issue with the whole = deployment descriptor issue, and have each type optionally declare a = "property" that would be used to set it. (the DD issue comes into play = because the third declaration by necessity breaks the ability to use the = simple properties file to map the element name to the class) By default, the property could be the type itself, e.g. 's = property would be "path", and 's property would be = "condition". I have an implementation that I'm modifying now to serve as a proof of = concept. Its from some code I wrote last year (and currently in = production) that uses a to Class mapping to parse XML into = objects. Incidentally, my original code had the same problem Ant does of = assuming that the was the same as the property name. Probably = because I got the idea for the code from looking at how Ant works, but = was unable to extract something generic that I could use. :-) I should (in between day-job and family commitments) be able to post = this some time this week. Does the general idea though, of actually registering the property name = work for people? I think it seems fairly obvious, especially when the = default is to use the element name. Tim List: ant-dev Subject: [IDEA] Polymorphic types From: Conor MacNeill = Date: 2001-11-16 13:50:01 [Download message RAW ] Attached is a patch to the IntrospectionHelper to give a little=20 ploymorphic behaviour for nested elements. I haven't committed this as I = thought I'd get some reaction first. Basically what this patch does is the following: When a nested creator=20 cannot be found for a particular nested element, a check is done to see=20 if the element corresponds to a datatype. If it does, a search is done=20 for a superclass of the datatype for which the class does have an addXXX = style creator. In practice, this allows me to use derived types with core tasks without = needing to change the core task. For example, if I wanted to use a=20 classfileset type in a task, I do not need to change copy to add=20 a addClassfileSet() method. I can just use this Similarly, I can have classfilesets in jars without changing the =20 task. It isn't perfect since some tasks use rolenames in their nested elements For these tasks, the current method of refids needs to be used.=20 Nevertheless, I think the patch is useful and makes it much more=20 meaningful to define derived types. The patch as it currently stands is just a proof of concept. There are=20 some inefficiencies which can be factored out if required. Let me know what you think? Conor -- To unsubscribe, e-mail: = For additional commands, e-mail: = -- To unsubscribe, e-mail: For additional commands, e-mail: