Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 76449 invoked from network); 30 Jan 2002 03:49:02 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 30 Jan 2002 03:49:02 -0000 Received: (qmail 25286 invoked by uid 97); 30 Jan 2002 03:49:07 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 25241 invoked by uid 97); 30 Jan 2002 03:49:06 -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 25230 invoked from network); 30 Jan 2002 03:49:06 -0000 Reply-To: From: "Tim Dawson" To: "'Ant Developers List'" Subject: RE: [IDEA] Polymorphic types Date: Tue, 29 Jan 2002 21:50:27 -0600 Message-ID: <002601c1a941$4241c720$6501a8c0@hagrid> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <005f01c1a918$eb7f9200$0100a8c0@jose> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Sorry I wasn't as clear as I could have been. Imagine the following antlib deployment descriptor: if a build file was encountered that had The implementation of the Condition task and the Condition types (And, Os, Not, etc) would have been much simpler. Instead of all the addAnd() addOs() addNot() etc. methods, there would have been one addCondition() method in the ConditionTask class and one addCondition() method in the ConditionType abstract superclass (which would no longer need to inherit through the task hierarchy). This result is the same as what Conor proposed, the difference in what I'm proposing is how you determine what add() method to call -- something more well-defined, like the suggested deployment descriptor, or guessing based on introspecting superclasses (& eventually implemented interfaces), which is more flexible but less deterministic? Tim > -----Original Message----- > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com] > Sent: Tuesday, January 29, 2002 5:02 PM > To: Ant Developers List > Subject: Re: [IDEA] Polymorphic types > > > Can you give an example of your proposal? > > I really do not understand how it works. > > Jose Alberto > > ----- Original Message ----- > 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 > 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 > cannot be found for a particular nested element, a check is > done to see > if the element corresponds to a datatype. If it does, a > search is done > 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 > classfileset type in a task, I do not need to change > copy to add > a addClassfileSet() method. I can just use this > > > baseclass="build/classes/org/apache/tools/ant/Main.class"/> > > > > Similarly, I can have classfilesets in jars without changing > the > 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. > Nevertheless, I think the patch is useful and makes it much more > meaningful to define derived types. > > The patch as it currently stands is just a proof of concept. > There are > 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: > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com -- To unsubscribe, e-mail: For additional commands, e-mail: