ant-dev mailing list archives

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

> From: "Jose Alberto Fernandez" <>
> > 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).
> Didn't I agree it was a 'hack'?  Misusing a datatype cannot be
> the reason to summarily reject a datatype itself!  The misuse is
> what is to be rejected.

I do not want to duel on this. We may just have different points of view.

> > 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;
> >    }
> Passes the buck to the task writer.  

Where it belongs, since only the task writer knows what are the requirements
of the task.

> We have seen that
> the task writer isn't always checking all the reqd. validations
> are done.  Also, are you suggesting we have
> mustNotExist(), mustNotBePlain(), etc

I do not know which validators should be provided out of the box,
but in any case this would be more comprenhensive than what 
you do in the constructors of your types.

I think the basic high level validations are:


we may also want to have evaluators like:

    isSrcDir(), isDestDir(), isSrcFile(), isDestFile()

in case users require some more complex validation than the ones
offered out of the box. Some more lower level validations will
be interesting to have:

    mustExist(), mustbeDir(), etc. 

we do not need to offer all in all, we just need to offer the basics,
people that need more may write the code themselves or may subclass
and extend with additional validators.

> I also wonder how to manage in your case 'Or' type situations
> where either the file must exist or it must be plain.  Handling
> these in the 'catch' parts would make it convoluted.

see above. How do your solution deals with such 'Or' situations?
Can it be handled at all?

An additional reason why I have problems with your approach is that
it assumes that parameters must be valid at the time the attribute is set,
and not when they are actually used (execute). Although the two events
may occur at close time for most tasks, this may not be the case for
always, like for example in the case of a DataType.

For datatypes, you may have the declaration operation ( when the attributes
are set) happening quite early in the build process, while the actual usage of the
datatype by some task may occur much later. in such cases we may want to
wait for the validation to occur when the reference is used.

I do not see how this can be acheived by your approch (unless you just do not use it).

Jose Alberto

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

View raw message