Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47154
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain keryx.se designates 208.69.121.33 as permitted sender)
Message-ID: <4B9A2849.9050806@keryx.se>
Date: Fri, 12 Mar 2010 12:40:57 +0100
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc12 Lightning/1.0b1 Thunderbird/3.0.3
MIME-Version: 1.0
To: internals@lists.php.net
References: <4B9926E8.4080202@lerdorf.com>
In-Reply-To: <4B9926E8.4080202@lerdorf.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 6 as we know it suddenly died?
From: webmaster@keryx.se (Keryx Web)

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/