No, but there are related issues that come up.
For example, once we remove the third string type (leaving only binary
and unicode) we lose the ability to have automatic BC support for
functions that have not been upgraded and still do RETURN_STRING().
Something like:
dirname(__FILE__)."/myfile.php";
will issue a "cannot concatenate binary with unicode" error.
This does "break" PHP until we go through these functions and make them
do the right thing. Can we live with it? Possibly, and it might even be
good because it would light a fire under everyone's butt to upgrade the
functions they are responsible for or cannot live without.
Another question is whether we still need the runtime_encoding setting
and the corresponding converter. I initially thought that we can
discard it, but there are many functions in PHP that use some
underlying C function and in order to convert its result into Unicode
they need to use some encoding. Whether we default to UTF-8, use
default system encoding, or retain runtime_encoding setting needs to be
discussed.
- Andrei
On Dec 12, 2005, at 12:10 AM, Derick Rethans wrote:
Have we finalized our Unicode decisions? I was talking to Dmitriy
online and
we had some initial disagreement over which internal string types to
keep,
IS_BINARY/IS_STRING or IS_STRING/IS_UNICODE. My point was that since
Unicode
strings will be available both with unicode_semantics switch on and
off, then
IS_UNICODE should remain invariant and it is IS_STRING that changes
behavior
(however slightly).
It would help a lot for all of us to get involved in this, at least
partially.
I thought we discussed this quite intensively at the meeting. And afaik
we concluded on:
http://www.php.net/~derick/meeting-notes.html#different-string-types
Do you want to re-asses this now?
--
PHP Unicode & I18N Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
