commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Cooper <mfncoo...@gmail.com>
Subject Re: [io] FilenameUtils
Date Sat, 30 Oct 2004 22:31:58 GMT
On Sat, 30 Oct 2004 22:48:19 +0100, Stephen Colebourne
<scolebourne@btopenworld.com> wrote:
> > A first question to ask is, what is the class FilenameUtils for? The
> > immediate answer is utilities for filenames. ie) the Wildcard code.
> 
> Hmm, there seems to be a difference of view over what FilenameUtils is
> about. You have evaluated method based on whether they manipulate filenames.
> I was expecting there to also be methods in there that do file operations,
> but without creating a File class yourself. I can cope if we want to exclude
> this second group of methods, but we need to clearly scope the class.

I expected that FilenameUtils would manipulate file names, no more, no less.

> > // 1) These 3 should be deleted. They are file based, not filename based.
> >     boolean fileExists(String fileName)
> >     void fileDelete(String fileName)
> >     void mkdir(String dir)
> Thus, these are fine for me (depending on the scope of the class), except
> for the names which should match exactly the File methods - exists, delete,
> mkdirs.

I would have expected these methods to show up in FileUtils rather
than FilenameUtils. In fact, I doubt it would ever have occurred to me
to look for them in the latter.

> > // 2) These are all simple with Lang StringUtils; but acceptable as
> semantic.
> >     String removeExtension(String filename)
> >     String getExtension(String filename)
> >     String removePath(String filepath)
> >     String getPath(String filepath)
> These seem fine as filename manipulation methods, avoiding unix/windows
> style errors. Should the removePath method be getName (ie positive rather
> than negative)?
> 
> > // 2.1) Not convinced these two should exist. People should use
> > StringUtils if they're not
> > //         dealing with their own file-system.
> >     String removePath(String filepath,char fileSeparatorChar)
> >     String getPath(String filepath,char fileSeparatorChar)
> These seem bad.
> 
> > // 3) This one does make sense, but it's UNIX specific currently. It's
> > the one that should have a fileSeparatorChar argument.
> >     String normalize(String path)
> Needs fixing
> 
> > // 4) Less compelling, but seems acceptable. It works on MS and UNIX.
> >     String catPath(String lookupPath, String path)
> I dislike the name. How about merge()
> 
> > // 5) Not impressed by this one. I'm not convinced it would actually
> > work. catPath relies on it.
> >     int indexOfLastPathSeparator(String path)
> Doesn't getPath() also need this same concept. Sounds like some refactoring
> here
> 
> > // 6) Not a huge fan of this method. baseFile is an optional parameter
> > by looks of it; it lacks a good use-case as an example; but it is at
> > least filename based to a certain extent.
> >     File resolveFile(File baseFile, String filename)
> This just looks very odd
> 
> > 7) There are also two private methods. internalize and externalize.
> > Nothing uses the latter and the former is used by getExtension only
> > and should be inlined into its code. There is also an unused
> > INTERNAL_SEPARATOR variable that needs killing.
> I would vote to make them public. separatorsToUnix(), separatorsToWindows(),
> plus separatorsToSystem()

I deliberately didn't do that, because that isn't the intended
semantic. The intent is to convert to some internal form that we
standardise on amongst ourselves. It wouldn't matter if that internal
form used '?' as the separator. I happened to choose '/' based on
earlier comments on what the JDK does, but I certainly didn't think of
that as converting the separators to Unix style. Also, I made these
methods private because whatever we decide as for an internal form
shouldn't matter to any use of the class.

--
Martin Cooper


> 
> > So, any disagreements to the above?
> ;-)
> 
> Stephen
> 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message