ant-dev mailing list archives

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

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

Anyway, if we change the names of the new datatypes
to something more explanatory of what they do instead
of SrcFile, DestFile, etc.(which attach special meaning in the
Ant world), perhaps, this will become a mute issue?

> 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

As I said, these new datatypes were meant to solve repeated
validation patterns.  So, if the task's validation does not fit
the *general* pattern, task has to do its own validation as I had
described earlier using the wrapper objects manually.

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

Catch the misuse.  I think that this is easier than checking to
see if all the necessary 'must' methods that you suggest have
been invoked properly. In the end, it simplifies our job as well
as the task writer's.

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

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

Nobody is going to restrict what their task does (or is meant
to do) because they have to use container provided datatype.
It is the other way around - if my task's validation fits the datatypes
provided by Ant, I will use it, else I won't!

>
> Jose Alberto
>

Magesh




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