ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magesh Umasankar" <>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Date Fri, 04 Jan 2002 19:57:15 GMT
> From: "Jose Alberto Fernandez" <>

> 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

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.

public setSrcFile(File f) {
    srcFile = f;

public void execute() {
    try {
        SrcFile sf = new SrcFile();
    } catch (Exception e) {
        //handle exception however...

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.

> However, this does not mean that we cannot greatly simplify and
standardize the
> semantic checking of the arguments. For example, We could provide a
> 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().

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

> 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).

My implementation did not prevent this.

> Jose Alberto


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message