Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 24833 invoked from network); 5 Jan 2002 13:21:58 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 5 Jan 2002 13:21:58 -0000 Received: (qmail 28374 invoked by uid 97); 5 Jan 2002 13:21:54 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 28358 invoked by uid 97); 5 Jan 2002 13:21:54 -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 28337 invoked from network); 5 Jan 2002 13:21:53 -0000 Message-ID: <002c01c195eb$4b3bada0$0100a8c0@jose> From: "Jose Alberto Fernandez" To: "Ant Developers List" , "Magesh Umasankar" References: <026701c1955a$02bcafc0$c040d6d1@compaq> Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types Date: Sat, 5 Jan 2002 13:17:14 -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 From: "Magesh Umasankar" > > From: "Jose Alberto Fernandez" >=20 > > My reasons are quite simple. Tasks are the ones that need to decide = the > > semantics of their attributes. Diferent tasks in different = circumstances > > should be able to impose different constraints on their arguments. > > Imposing a blank semantics on all usages of an attribute limits = their > usage. >=20 > The implementation that I had provided did not hamper what > you are suggesting. The tasks could very well have taken in File > as argument to the setters and in the execute method, the task > writer could have chosen to have invoked the validator. > [...] > The implementation that I had provided only added the > ability for the container to help the taskwriter if she so > chose. That is, if the task writer *wants* to let the container > perform the semantic validation too because the task's > attribute takes in the semantically well-defined datatype, > the container will oblige. In other words, if the task > writer wants to do the check manually, she can. If the > task writer wants the container to do the validation instead, > it can. Note here that the task is in fact the one that > is deciding the semantic of the attribute. The task > chooses the semantics to either be checked by the > container or by its execute method. If it will help, > instead of making the isValid method generate > error messages, it can be modified to throw > specific exceptions for handling them better. >=20 It is a question of philosophy. If what you say is true, then why did = you fill thatin the case of the best way to modofy the = class was to use a DestFile type, even though the attribute is a SrcFile (but = with special rules). If we follow your thoughts above, then the correct solution would have = been to leave the signature as File and do the special validation inside. I think the = problem here is that the structure if the types gears the programmers to force using them, = even when that becomes contrived. Programmers will always go for letting the = container do the job ;-) So, that tells me that there is a conceptual problem somewhere, there = has to be a balance. > > However, this does not mean that we cannot greatly simplify and > standardize the > > semantic checking of the arguments. For example, We could provide a > datatype > > whose constructor makes certain the syntax is proper. And which = provides > > verification methods for the task to call in order to perform = standard > semantic checkings: > > > > mustExist() > > mustBeDirectory() > > > > including more complex checks like: mustBeSrcDir(). >=20 > This seems like the Helper class approach that Steve suggests. > The only problem I have with that is that the container > cannot help in any way. The task writer has to still > write code to check if the file is a srcfile, similar to how > he is checking now to see if it is a directory or if it exists, > etc. I would like to minimize such if...then...else checks if > possible. I am not suggesting we introduce validator classes > for everything imaginable - we just have validator classes > for certain well-defined semantic checks like SrcFile, > SrcDir, DestFile, DestDir. We create semantic > validators only if we believe these will be used > across tasks and not just in one task or two. If we find > that the validations are being repeated across > multiuple tasks without a validator, then, and only then > do we introduce a new validator. This will keep the > number of semantic validator classes we maintain to a > minimum. >=20 Notice that what I am talking about does not require more "if"s. I am talking about less different types and more high level validators implemented by those types. The pattern I would=20 like for implementing an attribute setter is as follows: public void setFile(FileObject f) { f.mustExist(); f.mustBePlain(); this.file =3D f; } Here FileObject (it really needs a better name) is an ANT type that=20 knows understands and verifies the syntax for files with respect to the=20 OS system in which you are running (in the constructor). The validator calls are "declarative in nature" they do all the = exception throwing and so forth. The user has to do extremely little. > > The point is that this gives a chance to the task to decide > > what does it wants to enforce but it does it in a standarized > > way (applying a standard set of definitions). >=20 > My implementation did not prevent this. >=20 True, nothing prevents me to treat everything as Strings and do=20 everything myself. But that is not the point, the point is what is the correct balance so that at the end people do not misused the features of the container, limit the power of their tasks just to make it fit on what the container currently provides. Jose Alberto -- To unsubscribe, e-mail: For additional commands, e-mail: