The large amount of the dual IS_UNICODE/IS_STRING will need to stay in the code base anyway as we will be supporting binary strings in PHP 6. So it's not accurate that all these maintance issues will be resolved by not supporting unicode_semantics=off.
I believe unlike what Andrei said, for a large community of ours (probably the majority) default unicode_semantics=on will not be of interest (we don't live in a purists world). Many won't want to run it because it's going to be significantly slower and will be harder for them to work with. This community will be best served to be able to run in native 8bit mode and having some Unicode functionality available if/when needed. Having dual mode in PHP 6 is not the same as forking two code bases. There is still like namespaces automatically reach both audiences. If we're talking from a pure "what is most useful to the majority of our users" I'd actually argue that explicit Unicode strings would be the most convenient, i.e. instead of doing b"8bitstring" you'd do U"unicodestring". Other languages do the same and there are reasons for that. As we've decided on a more aggressive (and risky) approach, I think having this dual mode is extremely important. It will also make the upgrade path easier. Btw, I don't know how many of you have actually tried to port PHP 5 apps to PHP 6 but it's quite a disaster. We made some fixes in the past 2-3 weeks and its getting better but it still requires a lot of work. If we don't make this easy then this is all not worth too much. This project has never been a purists project which is why it's been so successful, let's not start now... Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
