FW: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
| From: | Andi Gutmans | Date: | Tue, 22 Jan 2008 00:20:29 +0000 |
| Subject: | FW: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP | ||
| Groups: | php.internals | ||
| Request: | Send a blank email to internals+get-34863@lists.php.net to get a copy of this message | ||
Hi,
I agree that having such a switch is not going to be a good strategy. The main reason is the
headache application authors are going to have with compatibility especially when it comes to hosted
pre-configured environments and/or dedicated servers that run more than one application.
I think these are the main reasons and not maintenance costs because at least 80% if not more of the
dual-code in PHP today will still be needed after removing the switch because we will still support
both the binary and Unicode types. So for those who think this means we only support one data type
in PHP extensions and we don't need to port 4000 PHP functions that is not the reality. We will
still need to deal with IS_STRING and IS_UNICODE in the extensions.
As we have discussed in the past the migration path may be extremely hard moving from PHP 5 to PHP
6. Therefore the community has to come together and really invest in the migration path more than we
have in the past (like we did from version 2 to 3). This means that during the development process
we do port applications to PHP 6 and make sure to capture that process for our users. Preferably we
can have automated migration scripts, php.ini with defaults that allows for easy migration and well
documented migration steps.
Depending on how much pain we discover I think we should still agree to be open to the idea that
Unicode strings would be explicit (e.g. u"foo") as opposed to the default (someone else
mentioned it on this thread). Obviously this would depend on what we find when we work on the
migration methodology as there's not enough input to make that judgment call today. Also we
will see a lot of pain when it comes to anything which is coming in from the outside PHP so we may
very well see changes in those areas as the breakages become more apparent (e.g. file system, GPC
...). Performance benchmarks may also come in handy as a data point for whether we go down the
explicit or implicit route for Unicode strings.
I also think that one thing we are doing right which Perl didn't is the notion of PHP 5.3 where
we are able to more incrementally release a subset of the major features. This reduces the amount of
moving parts, the migration path and ultimately the risk for delivering a high quality PHP 6. Also
users get incremental value while we work on stabilizing PHP 6 and deal with issues like the
migration path.
Net, net - I agree that the unicode semantics switch is going to bring along more harm than good in
the long term. Let's just not fool ourselves with what we have to get done in order to make PHP
6 a success. Hopefully a lot of the new active people on this list can step up and help the rest of
the core team both with porting functions to PHP 6 and also help with the methodology.
Andi