Unicode support is a rather major milestone for PHP. It is one of the
biggest changes to the codebase ever. I don't think anybody can
seriously argue that decent Unicode support isn't worth the effort and
it is somewhat unrealistic to think that this can be done while keeping
it perfectly backward compatible to code written for PHP 4 released 7
years ago.
I am one of these people, I was forced to use ColdFusion for Unicode support
(website in Japanese), and not PHP, which I prefer.
We have tried very hard over the years to make sure we keep backward
compatibility much to the chagrin of a lot of people. Many people think
we should make a clean break from some of the legacy features of older
versions while others think we need to be backward compatible above all
else. This is a balancing act where we think long and hard before
making changes that can break old code, but in order to advance
sometimes there is no way around it.
I am testing my 25000 lines PHP5 application on PHP6, just to see what
changes it would require. I changed exactly 5 (yes only 5) lines of code,
and it worked perfectly except for the functions that requires binary string
parameters with a (binary) typecast.
What I am thinking is, if unicode_semantics=on, every single time I need to
call urlencode (or other binary-only functions) with a variable, I need to
typecast it. Well, if this is necessary 100% of the times, why not do this
already inside urlencode, and if the string contains bad characters, give
the same warning I get on the (binary) typecast on an incompatible string? I
am just trying to think logically, I don't know the amout of work something
like this would generate.
If this is done, ate least 1 25000 lines PHP application will work on PHP6
with 5 line changes. I think this is great marketing for PHP6 migration.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
