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 Fri, 04 Jan 2002 02:01:29 GMT
From: "Magesh Umasankar" <>

> From: "Jose Alberto Fernandez" <>
> > Oh I do not mind having classes that do the syntactic verification
> > if the default Java classes do not. That I think it is fine. Where
> > I have a problem is when we try to go beyond syntax into semantics.
> Differentiating between syntactic and semantic validations
> make sense in client-server/servlet-EJB environments.  But
> why should we be differentiating between them in Ant?  After all,
> if we do not do semantic validation during 'setting' tme, it is going
> to be performed (hopefully) in the execute method - there are
> no multiple layers involved here (at least ATM).  Do you suggest
> against doing semantic validations during 'setting' time because
> you envision Ant being used in some sort of a client-server
> env where setters are called by the client and execute is called
> by the server?  Or is it something else?

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.

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:


including more complex checks like: mustBeSrcDir().

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

It also means that developers may subclass the standard types and provide their own
enforcement rules for their tasks. 

Something like that seem much more flexible to me.

Jose Alberto

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

View raw message