Makoto, ok, thanks. Now I see. You are saying that the multi-byte extension took the opposite approach and made existing str*() byte oriented and the mb_str*() character oriented.
So we have: s2m) Migration from singlebyte to multibyte: change code that needs character units to use mb*() s2u) Migration from singlebyte to (new) Unicode: change code that needs byte units to use new functions. m2u) Migration from multibyte to Unicode: change str*() code that needs byte units to use new functions and (perhaps) change mb*() functions back to str*(). ugh! and some folks are using the multibyte extension as their current unicode solution so that the case m2u additionally represents migration from unicode to unicode when the php version changes. That would bear some additional consideration. But, in looking at the mb* doc, the str*() functions can be overloaded to use the mb*() character semantics. If a good number of users do that, then it isn't much consequence either way (ie it is no-win), and that puts us back to the original proposal. Is that right? Tex Texin Internationalization Architect, Yahoo! Inc. > -----Original Message----- > From: Makoto Tozawa [mailto:[EMAIL PROTECTED] > Sent: Thursday, August 25, 2005 5:30 PM > To: Tex Texin > Cc: 'Andrei Zmievski'; [EMAIL PROTECTED]; 'PHP > Developers Mailing List' > Subject: Re: [PHP-DEV] Re: PHP Unicode support design > document-keeping existing functionality > > > > If we don't make the functions provide reasonable behavior for > unicode, then every program needs to be rewritten to change > function names. > > I agree. I asked it because the Backwards Compatibility > section states > the following: > > "... the upgrade to Unicode-enabled PHP has to be transparent. This > means that the existing data types and functions must work as > they have > always done." > > For those functions written for single byte encoding, the upgrade to > Unicode-enabled PHP will be transparent because the character > semantics > remains same. For those functions written for multi byte > encoding using > mb_str*() functions, it will be also transparent. > > It is okay if there is no way to save those functions written > for multi > byte encoding abusing the str*() functions. > > Makoto > > > Tex Texin wrote: > > >1) sorry I am compelled to change the subject so all threads > don’t look > >the same. > > > >2) It's a no-win situation. If we don't make the functions provide > >reasonable behavior for unicode, then every program needs to be > >rewritten to change function names. The number of places where hard > >coded constants (6) are used is probably much smaller. > > > >At least this way most code does the right thing as-is. > > > >Also, if you don't want functions to show unicode behavior, leave > >unicode off, and just convert the data to utf-8. > > > >We do need to have functions that provide the raw byte length, so it > >will be available. > > > >Tex Texin > >Internationalization Architect, Yahoo! Inc. > > > > > > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
