commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christoph.R...@dlr.de
Subject Re: [io][vote] FileUtils: decision on style
Date Tue, 29 Jul 2003 08:20:00 GMT
Hey thanks for the heads up!

being one of the original authors/contributor of this class, I do
have some comments (mostly in favour of your proposal)...

1rst: you seem to have added a private constructor to prevent
instantiation, which hurts usage as in velocity, where you need
an instance of a class to allow the introspection to work. I'm
-1 for that change in CVS.

Jeremias Maerki wrote:
> In FileUtils we currently have many duplicate method due to merging
> classes from several sources. For example, there is a extension(String)
> and getExtension(String) method.
> 
> (Ironically, both have the same bug: "/tmp/foo.bar/README" evaluates to
> "bar/README".)

Oops. Make that into:

     public static String extension(String filename) {
+       int lastSep = filename.lastIndexOf(File.separator) + 1;
         int lastDot = filename.lastIndexOf('.', lastSep);

         if (lastDot >= 0) {
             return filename.substring(lastDot + 1);
         } else {
             return "";
         }
     }

> 
> So, we have to decide how these methods should be named. extension(),
> basename(), dirname() etc. are all named after their UNIX equivalents.
> getExtension(), removeExtension(), getPath() etc. are more Java-like and
> more descriptive (IMO).
> 
> I'm +1 for following the latter style.

+1, for the Java-like style.

> 
> 
> Then, there are methods like fileCopy(String, String) and copyFile(File,
> File).
> 
> I'm +1 for the "do-what"-style (in contrast to "what-do"), following
> Steve McConnell's Code Complete (from 5.2, Good Routine Names: "For a
> procedure name, use a strong verb followed by an object").
> 

Also +1 for the "do-what"-style: fileCopy(String, String)

> 
> In the meantime I'm writing some badly needed testcases for FileUtils...
> :-)

Cool.

> 
> Jeremias Maerki
> 

You commented the fileRead to be platform dependant, due to the
implicit encoding.

We should vote to cleanup the FileUtil class from the reading/writing
parts; possible solutions:
a) add a fileRead(fileName, encoding) form.
b) use a) and deprecate the original form.
c) remove the methods alltogether in favour of the building blocks
    in IOUtil (where methods with explicit encoding exists).

I'm +1 for overloading with a) only.

-- 
:) Christoph Reck


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