Hello,

I'm not crazy about the new unicode api.

Unicode support is essential so I'm not arguing against having it. What bugs 
me is the api.

It's criminal that the programmer is forced to state the encoding at every 
corner where a filename is involved. Stream data is either "text" or "binary" 
and it's often clear from the context which of the two is the case. For 
example:

        "out" [ . ] with-file-writer

OK, it's clear that I'm printing source code to a stream, so it's "text" 
not "binary". And in my case, *every friggin time* that I'm putting text into 
a file, it's utf8. It's sooo silly that I'm forced to say "this is utf8" 
every time I'm dealing with text.

If I write some text to a file and later I read the same file, guess what... 
the encoding doesn't matter. If I'm exchanging data with somebody else (or 
something else) then I *might* start to care and it's nice to be able to 
override the encoding.

        In all of my code, I have no need to care about the text encoding.

I would prefer a default text encoding of 'utf8'. Any stream could have it's 
encoding changed by setting it's 'encoding' slot. I think that an api based 
on a dynamic 'encoding' variable would have been worth exploring too. To be 
fair to folks for whom 'utf8' is not a good default, there should be a way to 
change the default.

For dealing with binary files, I'm in favor of words like 'read-byte' 
and 'write-byte'. These would simply ignore the encoding.

The new changes impact all code which use streams. Had we used an api based on 
an 'encoding' variable or a "default" encoding, most of the existing code 
would have continued to work. The exceptions would have been code that dealt 
with binary streams.

Slava and Dan already know how I feel about this. I just wanted to put out a 
voice on this issue.

Ed

-------------------------------------------------------------------------
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

Reply via email to