Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 26110 invoked from network); 31 Dec 2001 02:03:36 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 31 Dec 2001 02:03:36 -0000 Received: (qmail 11395 invoked by uid 97); 31 Dec 2001 02:03:41 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 11378 invoked by uid 97); 31 Dec 2001 02:03:41 -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 11367 invoked from network); 31 Dec 2001 02:03:40 -0000 Message-ID: <00b901c1919f$c2759d40$c040d6d1@compaq> Reply-To: "Magesh Umasankar" From: "Magesh Umasankar" To: "Ant Developers List" References: <00cd01c19101$cc11fbd0$22a0f40f@cv.hp.com> <002101c1914b$80b36620$c040d6d1@compaq> <200112302314.fBUNEDr08490@mail004.syd.optusnet.com.au> Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types Date: Sun, 30 Dec 2001 21:06:27 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4522.1200 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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: "Peter Donald" > Whats not straightforward about that? I feel it is not straightforward because it brings in the concept of a new 'preprocessor (?)' tool to generate the required code. I will try to illustrate below why having methods instead of meta data will be more powerful as well as straightforward. > > Can't we instead introduce methods like getSrcDirValidator, > > getSrcDirAttribute, getSrcDirDefault, isSrcDirOptional, etc? > > Im not sure how that is easier. It is not just a question of easiness. I feel we need to factor in flexibility also. For example, let us consider the scenario where we have the metadata tag suggested by Steve. * @ant:optional Here, all we can say is that this attribute is considered optional and if this method hasn't been invoked by the Introspector, it is OK. It is not always so straightforward. An attribute may be considered optional if another attribute is defined. For example, let's say task 's dir attribute *may* be specified if and only if the file attribute is not specified. If we choose the alternative 'method based' approach instead of meta data, it will let the task writer use the expressive power of the Java Language. Using methods, the above problem can be easily solved in an uncomplicated way. public boolean isSrcDirOptional() { if (srcFile == null) { return false; } else { return true; } } While this is a trivial example, there might be much more processing logic involved - like checking to see if a fileset has been defined, etc. So, embedding all these 'rules' in meta data will be tougher on the task writer because of extra learning involved, asuming we can come up with a nice syntax to express all these in meta data comments. Ant's introspection mechanism would start invoking attribute validators and corresponding setters in pairs. After exhausting them, it will start making checks to see is those attributes which are not 'optional' are set by invoking the isXXXOptional() methods... This way, we do not also need the new tool to preprocess special tags embedded as comments. All IMHO, of course. > > Pete > Magesh -- To unsubscribe, e-mail: For additional commands, e-mail: