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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

I might let you get away with:

public String readFileToStringUTF8(File f) {
return readFileToString(f, "UTF8");
}

or

public String (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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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

12/8/06, Stephen Colebourne <scolebourne (AT) btopenworld (DOT) comwrote:
I might let you get away with:

public String readFileToStringUTF8(File f) {
return readFileToString(f, "UTF8");
}

or

public String (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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
--

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

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 IUtils. In
IUtils we provide the default variant, in FileUtils we don't. In
IUtils 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

12/8/06, Henri Yandell <flamefew (AT) gmail (DOT) comwrote:
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

12/8/06, Stephen Colebourne <scolebourne (AT) btopenworld (DOT) comwrote:
I might let you get away with:

public String readFileToStringUTF8(File f) {
return readFileToString(f, "UTF8");
}

or

public String (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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>
>

To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

Henri Yandell wrote:
We have encoding in io.* in two places, FileUtils and IUtils. In
IUtils we provide the default variant, in FileUtils we don't.

Whatever the arguments for or against this, I prefer consistency if
possible. 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org

12/28/06, Stephen Colebourne <scolebourne (AT) btopenworld (DOT) comwrote:
Henri Yandell wrote:
We have encoding in io.* in two places, FileUtils and IUtils. In
IUtils we provide the default variant, in FileUtils we don't.

Whatever the arguments for or against this, I prefer consistency if
possible. 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 (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org