The rationale is that there is no dependably common case. Sometimes, when you're reading a stream, you want to read in UTF-8, and sometimes binary. Occasionally (for example, in SMTP) things are just ASCII. When writing English, these three things are often the same. However, when making an internationalized application, or even just one that reads curly quotes right, you want things to work correctly, interpreting UTF-8. Also pretty often, you need to open binary streams, and UTF-8 fails even worse when interpreting an arbitrary binary stream than the other way around.
When I went through the Factor code base and put in "binary" and "utf8" markings on opening streams when applicable, here's how often each encoding was used: utf8 is used 36 times, ascii is used 28 times, binary is used 29 times, utf16 is used 9 times and latin1 is used 6 times. (This count isn't perfect, though, as it includes the definitions themselves and some unit tests.) This doesn't give a strong argument towards either "binary" or "utf8" being a default encoding. There is no common case to optimize for. When one of these encodings are made the default, it can lead to bugs where a badly-thought-out program uses the wrong encoding because it happened to work for simple test cases; this is how the Factor library basically worked before encodings were done this way. The library could be structured to give additional words which used some default encoding, but these couldn't universally be used without additional, more awkward constructs that'd make it hard to use things like with-file-writer. (You'd have to do "path" <file-writer> binary >>encoding [ ] with-stream rather than "path" binary [ ] with-file-writer.) It would work poorly to have an encoding that's passed around in a dynamically scoped variable because the encoding of files would be modified by the caller in counterintuitive ways. Dan On Fri, Mar 7, 2008 at 6:34 AM, Phil Dawes <[EMAIL PROTECTED]> wrote: > Delivery of the argument aside, this does seem like a slam-dunk to me. > What's the rationale for not optimizing the common case? (i.e. that all > reads and writes are done to same encoding). > Or am I missing something? > > Thanks, > > Phil ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
