|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
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
Visit the Apple Store online or at retail locations.
Copyright © 2011 Apple Inc. All rights reserved.