Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 701 invoked from network); 29 Jan 2002 22:46:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Jan 2002 22:46:11 -0000 Received: (qmail 3057 invoked by uid 97); 29 Jan 2002 22:46:12 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 3040 invoked by uid 97); 29 Jan 2002 22:46:12 -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 3029 invoked from network); 29 Jan 2002 22:46:11 -0000 From: "Conor MacNeill" To: "Ant Developers List" Subject: RE: [IDEA] Polymorphic types Date: Wed, 30 Jan 2002 09:52:01 +1100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 In-Reply-To: X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N > -----Original Message----- > From: Tim Dawson [mailto:tim.dawson@notiva.com] > Sent: Wednesday, 30 January 2002 7:12 AM > To: ant-dev@jakarta.apache.org > Subject: Re: [IDEA] Polymorphic types > > > I like the idea of polymorphic types, but I'm not sure about this > type of implementation - Agreed. I was not happy with the implemntation. That is why I have not proceeded with this in Ant 1.x. The idea is, however, pretty good, IMHO. It would solve the problem of extensibility in ejbjar, for example. I have experimented further in mutant, which supports polymorphism, including allowing add methods to be defined in terms of an interface. > 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 guess I don't really follow what you are proposing here. What I did in mutant is have the name of the nested element identify the add method which will be called. An ant:refid attribute can be used to identify an existing instance to be passed to the method. Alternatively, an ant:type attribute can be used to identify an Ant typdef'd type, an instance of which is to be created. Introspection/reflection proceeds using this type instance. Finally, if no ant:refid or ant:type is used, mutant will try to create an instance of the argument type of the add method. > 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. > Ummm, not sure. :-) Conor -- To unsubscribe, e-mail: For additional commands, e-mail: