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
