Return-Path: Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 2624 invoked from network); 21 Apr 2000 16:00:17 -0000 Received: from mercury.sun.com (192.9.25.1) by locus.apache.org with SMTP; 21 Apr 2000 16:00:17 -0000 Received: from shorter.eng.sun.com ([129.144.174.35]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA18901 for ; Fri, 21 Apr 2000 09:00:17 -0700 (PDT) Received: from eng.sun.com (pra-rem-8.Czech.Sun.COM [129.156.75.109]) by shorter.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v1.7) with ESMTP id JAA06679 for ; Fri, 21 Apr 2000 09:00:12 -0700 (PDT) Message-ID: <39007980.36DD69C0@eng.sun.com> Date: Fri, 21 Apr 2000 08:53:36 -0700 From: James Duncan Davidson X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: ant-dev@jakarta.apache.org Subject: Re: Ant Principles (Design pattern) References: <852568C8.0045E7FC.00@d54mta04.raleigh.ibm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > > + Object is created inside task, so no need to find the correct > > type in some intelligent way. This makes the creation a lot > > faster, and might prevent classloader problems. True, but then the programmer is responsible for providing that. > > + No conflict with the addText(String) method > > - When the task is encapsulated, you cannot add an existing > > object of the correct type. You have to create a new one > > with createXxxx to add it, and fill the fields. Right, and this is a big negative. The ability to do things of this nature without having to create your own class types would be nice. > Excellent summary. Key point is that neither is "wrong" or unworkable. > > After Duncan reemerges from radio silence, lets quickly come to a > consensus. Yes.. Lets. :) > I woud just rather that Ant didn't support both (except, perhaps briefly as > a migration aid). +1