You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <fl...@gmail.com> on 2006/12/08 23:40:18 UTC
[io] Non-encoding versions of readFileToString etc
As it's highly irritating to use as a user, I wanted to confirm that
we were still -1 to having:
public String readFileToString(File f) {
return readFileToString(f, null);
}
and the various other overlays?
It sucks to keep adding null all over the place.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Non-encoding versions of readFileToString etc
Posted by Henri Yandell <fl...@gmail.com>.
On 12/28/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> Henri Yandell wrote:
> > We have encoding in io.* in two places, FileUtils and IOUtils. In
> > IOUtils we provide the default variant, in FileUtils we don't.
>
> Whatever the arguments for or against this, I prefer consistency if
> possible. On reviewing the code in more detail, we do have defaults for
> encoding, and defaults for other parameters as well. There is thus no
> overriding good reason not to allow these additional defaulting methods.
> If you want them, go ahead and add them ;-)
Will do :)
[opening a JIRA so I don't forget]
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Non-encoding versions of readFileToString etc
Posted by Stephen Colebourne <sc...@btopenworld.com>.
Henri Yandell wrote:
> We have encoding in io.* in two places, FileUtils and IOUtils. In
> IOUtils we provide the default variant, in FileUtils we don't.
Whatever the arguments for or against this, I prefer consistency if
possible. On reviewing the code in more detail, we do have defaults for
encoding, and defaults for other parameters as well. There is thus no
overriding good reason not to allow these additional defaulting methods.
If you want them, go ahead and add them ;-)
Stephen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Non-encoding versions of readFileToString etc
Posted by Henri Yandell <fl...@gmail.com>.
Sorry to reply to my reply, but I figure I kept on digging and having opinion:
We have encoding in io.* in two places, FileUtils and IOUtils. In
IOUtils we provide the default variant, in FileUtils we don't. In
IOUtils we say:
"You are encouraged to always specify an encoding because relying on
the platform default can lead to unexpected results, for example when
moving from development to production."
This seems incorrect to me. If I set the encoding so it works on my
development machine, it's going to fall over when it goes to
production (assuming the implied difference). However if I rely on the
default encoding, then it'll work fine. This does rely on the
application being in charge of writing and reading the file; or at
least the machine it is on being in charge of that; but that seems to
me to be a more common use case by far.
I'll shut up now and let people reply.
Hen
On 12/8/06, Henri Yandell <fl...@gmail.com> wrote:
> Suspected that would be suggested.
>
> If it's the best I can get, then it's tempting despite the lengthy
> nature; but given that java.lang.String's constructors have
> default-encoding versions, as does String.getBytes(), it really
> doesn't seem like the end of the world to allow the default to be
> default.
>
> The assumption that the app you've written is being given files that
> match the platform you're on seems a very fair one to me. If it turns
> out that's not the case, then much of the time my app isn't going to
> be able to do anything about it anyway bar throw an exception to which
> the fix will be 'fix the encoding of the file'.
>
> Hen
>
> On 12/8/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> > I might let you get away with:
> >
> > public String readFileToStringUTF8(File f) {
> > return readFileToString(f, "UTF8");
> > }
> >
> > or
> >
> > public String readFileToStringDefaultEncoding(File f) {
> > return readFileToString(f, null);
> > }
> >
> > Stephen
> >
> >
> > Henri Yandell wrote:
> > > As it's highly irritating to use as a user, I wanted to confirm that
> > > we were still -1 to having:
> > >
> > > public String readFileToString(File f) {
> > > return readFileToString(f, null);
> > > }
> > >
> > > and the various other overlays?
> > >
> > > It sucks to keep adding null all over the place.
> > >
> > > Hen
> > >
> > > ---------------------------------------------------------------------
> > > 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
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Non-encoding versions of readFileToString etc
Posted by Henri Yandell <fl...@gmail.com>.
Suspected that would be suggested.
If it's the best I can get, then it's tempting despite the lengthy
nature; but given that java.lang.String's constructors have
default-encoding versions, as does String.getBytes(), it really
doesn't seem like the end of the world to allow the default to be
default.
The assumption that the app you've written is being given files that
match the platform you're on seems a very fair one to me. If it turns
out that's not the case, then much of the time my app isn't going to
be able to do anything about it anyway bar throw an exception to which
the fix will be 'fix the encoding of the file'.
Hen
On 12/8/06, Stephen Colebourne <sc...@btopenworld.com> wrote:
> I might let you get away with:
>
> public String readFileToStringUTF8(File f) {
> return readFileToString(f, "UTF8");
> }
>
> or
>
> public String readFileToStringDefaultEncoding(File f) {
> return readFileToString(f, null);
> }
>
> Stephen
>
>
> Henri Yandell wrote:
> > As it's highly irritating to use as a user, I wanted to confirm that
> > we were still -1 to having:
> >
> > public String readFileToString(File f) {
> > return readFileToString(f, null);
> > }
> >
> > and the various other overlays?
> >
> > It sucks to keep adding null all over the place.
> >
> > Hen
> >
> > ---------------------------------------------------------------------
> > 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [io] Non-encoding versions of readFileToString etc
Posted by Stephen Colebourne <sc...@btopenworld.com>.
I might let you get away with:
public String readFileToStringUTF8(File f) {
return readFileToString(f, "UTF8");
}
or
public String readFileToStringDefaultEncoding(File f) {
return readFileToString(f, null);
}
Stephen
Henri Yandell wrote:
> As it's highly irritating to use as a user, I wanted to confirm that
> we were still -1 to having:
>
> public String readFileToString(File f) {
> return readFileToString(f, null);
> }
>
> and the various other overlays?
>
> It sucks to keep adding null all over the place.
>
> Hen
>
> ---------------------------------------------------------------------
> 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