commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From __matthewHawthorne <mehawtho...@earthlink.net>
Subject Re: [io][vote] FileUtils: decision on style
Date Tue, 29 Jul 2003 13:29:38 GMT
If others can't deal with private constructors, then I guess there isn't
a choice.  

But in theory, I think protected constructors would be the best since
they would allow the constructor to be accessible to subclasses, if
necessary.




On Tue, 2003-07-29 at 05:53, Jeremias Maerki wrote:
> On 29.07.2003 10:20:00 Christoph.Reck wrote:
> > 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.
> 
> Well, private constructors in pure utility classes are rather common. I
> think Velocity should be flexible enough cope with that. Anyway, I'm
> going to revert that change, but I'm not 100% comfortable with the whole
> thing. Other opinions?
> 
> > 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 "";
> >          }
> >      }
> 
> Nah. I'm not going to hack a fix whereever a problem occurs. I want to
> improve on all methods in FileUtils simultaneously and with a concept
> and unit tests.
> 
> <snip/>
> > > 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)
> 
> Uhm, fileCopy is "what-do". :-) Now, what do you prefer?
> 
> <snip/>
> 
> > 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.
> 
> I'm +1 for b) because leaving the method without the encoding parameter
> encourages bad style. b) makes you think twice what you're really doing.
> 
> But there's another topic in there. The JDK throws
> UnsupportedEncodingException for all methods with an encoding parameter.
> You always have to catch that and 95% percent of the instances you catch
> this exception you will end up throwing a RuntimeException with a
> message like "Incompatible VM. Encoding xy is not supported" (my
> experience). I'd rather throw something like a IncompatibleVMException 
> (extends RuntimeException) in these methods. Of course, that behaviour
> must be properly documented in Javadocs.
> 
> Jeremias Maerki
> 
> 
> ---------------------------------------------------------------------
> 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