On Fri, 21 Dec 2001 Steve Loughran wrote :
> {zip,tar,jar,gzip,bzip} tasks, giving them a
> consistent use of srcFile, srcDir, destFile and
> destDir. This is for consistency,
Maybe we should go one step further by creating new
classes - SrcFile, SrcDir, DestFile, DestDir - all of
which extend from java.io.File, but have the following
distinct features:
1. If setSrcFile(SrcFile) is used, and if SrcFile does
not exist or if it is a directory, SrcFile's constructor
throws IOException which results in a BuildException
being thrown.
2. If setSrcDir(SrcDir) is used, and if SrcDir does not
exist,or if it is not a directory, SrcDir's constructor
throws IOException which results in a BuildException
being thrown.
3. If setDestFile(DestFile) is used, and if DestFile
exists, but is a directory, DestFile's constructor
throws IOException which results in a BuildException
being thrown.
4. If setDestDir(DestDir) is used, and if DestDir
exists, but is not a directory, DestDir's constructor
throws IOException which results in a BuildException
being thrown.
This way, we can avoid repeating a lot of code in lots of
tasks checking if a file is a directory or not, depending
upon the context. This, IMHO, is necessary because
there are currently approximately 40 built-in tasks
(rough count after performing grep) that have checks for
isDirectory() and I think most of these follow a
pattern, which we should be able to abstract away.
Of course, this would mean modifying the Introspection
Helper (again), such that these four new classes take
precedence over java.io.File, to be backwards compatible.
> None of this would break anything, we just add more
> 'deprecated' cruft (sigh), but gain a simpler
> conceptual model for end users.
Conceptual, as well as programmatic, if what I am
suggesting can also be put in place ;-)
My turn to ask "Comments?" :-)
Cheers,
Magesh
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
