On Sat, Feb 24, 2001 at 11:31:49AM -0600, William A. Rowe, Jr. wrote: > From: "Greg Stein" <[EMAIL PROTECTED]> > Sent: Saturday, February 24, 2001 3:44 AM >... > > In a similar vein, when you added all that Unicode stuff, it just kind of > > dropped into the code. No big deal as it was all Win32 specific (i.e. it > > didn't affect my playground), but it was an awfully big change. Especially > > in the semantics. We still haven't refactored the API into two sets of > > functions (one for Unicode chars, one for 8-bit native). > > I'm absolutely positively near certain we won't. Please let me explain. > > ... lot of stuff about why Unicode filenames are Goodness ...
I don't disagree with wanting Unicode filenames. I completely disagree with APIs that change their semantics based on the platform they are compiled on. If I have an application that I desire to be portable, then I'm going to use APR to do it. In my app, I call apr_file_open(some_8bit_name). That should work on all platforms. With the current single API, it will break on NT when compiled with the Unicode stuff. None of the APIs change their semantics. They exist or they don't, but they don't change. The answer is to have apr_file_open_u() for opening with Unicode filenames, not changing the encoding of the existing apr_file_open. You completely break all possibility of writing portable apps when you do that. And APR is *about* writing portable apps. Cheers, -g -- Greg Stein, http://www.lyra.org/
