Todd O'Bryan wrote:
>And this is the problem. Because when developers don't think about
>the issue (which, yes, we know they should, but they don't do lots of
>things they should), they create a FileWriter using the default
>encoding and create more crappy data. The people creating the tools
>should step up and prevent laziness from leading to crappiness as
>much as possible.
Maybe the people creating the tools believe that the tool users are
developers, and can do some things for themselves. If the users aren't
developers, or can't do things themselves that are clearly within their
powers, then is lowering expectations really going to solve anything?
Over the years, I've created various kinds of factory classes that handle
all the ugly details of opening text-files for me: user's preferred
text-encoding, inferring from file-types and/or suffixes as appropriate,
and so on. The one thing I've discovered is that there's no one thing that
always works. Sometimes you need more, sometimes you need less.
I wrote those different classes because I was being lazy, and I didn't want
to keep solving the same problem over and over again. Unfortunately, while
there is a central nugget that is recurring, it's the decorations that
vary, so it takes real thought and insight to make something clear,
concise, and elegant that meets a wide range of possible uses.
Since all the capability to interpret text-encodings, preferences,
suffixes, and other what-not is entirely withing the reach of any Java
developer, maybe a little research project should be started. Or at least
write a few web pages in the "X Considered Harmful" pattern, for X =
FileWriter, ignorance of text-encodings, "plain" text, or whatever seems
appropriate.
If there's an obvious solution, then it should precipitate out of a
practical project pretty rapidly. But if there isn't, then at least it
will act as a catalyst and a collection point for good ideas. When you get
enough good ideas, you end up with a well-designed well-factored solution
to a problem. Let it be so.
>If someone needs to read a text file from 1992,
>they can certainly ask for MacRoman as the encoding. But they
>shouldn't have to ask for UTF-8 if they want to write a file now.
Then create a class that does it, and publish the darn thing. It should be
practical and easy to create, use, reuse, and redistribute.
In my experience, ideas that solve real problems get adopted rapidly and
have a fruitful life. Ideas that don't solve real problems don't. And
I've written enough software in the latter category to be able to recognize
the difference, even if only in hindsight.
A strategy for inaction:
complain, wait for someone (or everyone) else, be impractical.
A strategy for results:
don't whine, think concisely, just do it.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
