ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types
Date Sat, 05 Jan 2002 13:17:14 GMT
From: "Magesh Umasankar" <umagesh@apache.org>


> > From: "Jose Alberto Fernandez" <j_a_fernandez@yahoo.com>
> 
> > 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.
> 
> 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.
> 

It is a question of philosophy. If what you say is true, then why did you fill
thatin the case of <property file="xyz" /> 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().
> 
> 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.
> 

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 
like for implementing an attribute setter is as follows:

    public void setFile(FileObject f) {
        f.mustExist();
        f.mustBePlain();
        this.file = f;
    }

Here FileObject (it really needs a better name) is an ANT type that 
knows understands and verifies the syntax for files with respect to the 
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).
> 
> My implementation did not prevent this.
> 

True, nothing prevents me to treat everything as Strings and do 
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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message