----- Original Message ----- From: "Magesh Umasankar" <[EMAIL PROTECTED]> To: "Ant Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, December 25, 2001 11:50 Subject: Re: cvs commit: jakarta-ant/src/main/org/apache/tools/ant/types DestDir.java DestFile.java PreferredAttribute.java SrcDir.java SrcFile.java ValidatedFileAttribute.java
> Hi, > > > Modified: src/main/org/apache/tools/ant IntrospectionHelper.java > > Added: src/main/org/apache/tools/ant/types DestDir.java > > DestFile.java PreferredAttribute.java SrcDir.java > > SrcFile.java ValidatedFileAttribute.java > > Log: > > IntrospectionHelper has been modified such that overridden setter > methods > > that take in 'PreferredAttribute's as argument gain higher precedence. > > New attribute types - SrcDir, SrcFile, DestDir and DestFile are > introduced. Each of these types is a PreferredAttribute. > > Let me provide the rationale behind this commit. > > A lot of the tasks that we have perform one validation or another before > performing the actual execution. One such validation that is commonly > repeated is the check to see if a file exists, if it is a directory, or if > it is a > file, etc. These are the common rules that most of the tasks check: > > 1. Src File must exist and must be a file. > 2. Src Dir must exist and must be a directory. > 3. Dest File may not exist, but if it does exist, it must be a file. > 4. Dest Dir may not exist, but if it does exist, it must be a directory. > > These new classes encapsulate this validation thereby minimizing > the validation code that the task writer has to write. > > I have modified IntrospectionHelper such that it stays backwards > compatible while at the same time takes advantage of the newly > introduced 'PreferredAttribute' mechanism. I look at PreferredAttribute > as a stop gap measure till Ant2 is released at which time, this may go off, > as we wouldn't be backwards compatible anyway. > > There are a lot of tasks that currently take in File as argument to the > setter methods. I will be refactoring these shortly, such that they take in > ValidatedFileAttributes as arguments. > After you suggested it, I was debating doing this when I went round tidying up some tasks. I dont think I would have done it as cleanly or completely as you did, so I am grateful. 1. I had debated whether to have a constructor which would validate and throw an exception, so SrcFile() could have 2 ctors; empty,File and string. The latter two would make back-patching into existing code easier as you could retain the string and file setters but create a SrcFile internally. The problem with this approach is that if someone subclassed SrcFile and overrode isValid, then it could be called from a parent constructor, which is always a bad thing. 2. having just read Effective Java, I am a fan of immutable datatypes. This isnt because setFile can be called repeatedly, and because the file reference isnt cloned. I dunno if either of these points are important enough to make any changes, I am happy enough with what there is. But I might be tempted to do them as I patch the datatypes into existing code. ...maybe we need an Ant Datatypes Guidelines.. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
