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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
