2010-03-11 18:22, Rasmus Lerdorf skrev: Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not, it is all about solving the Unicode problem. The current effort has obviously stalled. We need to figure out how to get development back on track in a way that people can get on board. We knew the Unicode effort was hugely ambitious the way we approached it. There are other ways. So I think Lukas and others are right, let's move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let's see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again.
Just to be clear about what is being discussed, since this sounds to me like everything Unicode will happen in functions and classes only. 1. Are you proposing that unicode strings disappear? 2. If so, what will happen to array access in strings that are de facto Unicode? Will the more clunky mb_substr() be the only option? 3. Will PHP ever reach a state where Unicode is the default encoding with this approach? I.e. will I ten years from now still write mb_strlen($foo, "utf-8") if I do not overload normal PHP functions? UTF-8 "marketshare" is rising steadily. More than 50 % of all new projects on the web use it. By 2015 I'd suspect that only legacy projects will be non-unicode and a great number of them will be in the process of converting. Somewhere in the future PHP must default to Unicode! As for naming. Releasing PHP 6 without the up until now proposed Unicode functionality will be confusing. Learn from ECMAScript and skip a number if that's the case. If the next update is small and incremental this analogy will hold: ES 5th ed <=> PHP 5.4 ES "harmony" <=> PHP 7 If the next update is quite big and breaks backwards compatibility in some ways, go directly to 7. This is written from a customer perspective. I am a PHP user and educator, not a code contributor to internals. But please listen anyway. We are the ones who will get confused, and we are the majority of all people who use your product. We are your customers ;-) -- Keryx Web (Lars Gunther) http://keryx.se/http://twitter.com/itpastorn/http://itpastorn.blogspot.com/
