Re: character/byte semantics was Re: PHP Unicode support design document-keeping existing functionality

From: Date: Fri, 26 Aug 2005 18:02:02 +0000
Subject: Re: character/byte semantics was Re: PHP Unicode support design document-keeping existing functionality
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-18478@lists.php.net to get a copy of this message 
Yes.

Makoto

Tex Texin wrote:


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:makoto.tozawa@oracle.com] Sent: Thursday, August 25, 2005 5:30 PM
To: Tex Texin
Cc: 'Andrei Zmievski'; christopher.jones@oracle.com; '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.


Thread (44 messages)

« previous php.internals (#18478) next »