Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47229
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: unknown (pb1.pair.com: domain php.net does not designate 82.113.146.227 as permitted sender)
Date: Sat, 13 Mar 2010 11:57:19 -0500 (EST)
To: Rasmus Lerdorf <rasmus@lerdorf.com>
cc: PHP Developers Mailing List <internals@lists.php.net>
In-Reply-To: <4B9926E8.4080202@lerdorf.com>
Message-ID: <alpine.DEB.2.00.1003131123540.4153@kossu.derickrethans.nl>
References: <4B9926E8.4080202@lerdorf.com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: Re: [PHP-DEV] PHP 6
From: derick@php.net (Derick Rethans)

On Thu, 11 Mar 2010, Rasmus Lerdorf wrote:

> 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.
> 
> The main focus here needs to be to get everyone working in the same 
> branch.

I am also in favour for getting back to one branch for new development. 
And that "branch" should be trunk. However, I am a little bit reluctant 
to just "kill" all Unicode support. I don't think we can get around the 
fact that propr Unicode support is going to be even more important in 
the future than it already is today. However, we can also not get around 
the fact that the current state of "Unicode-in-PHP" isn't the most ideal 
situation.

I do however think that most of the current approaches of adding Unicode 
support into PHP 6 (current trunk) have the proper ideas behind that, 
but I do think that in some cases we went slightly overboard of 
supporting Unicode everywhere with the new "unicode" type. For example, 
we don't really need to have this for variable or function names or 
support every encoding for writing scripts in. (We do 
need to *support* Unicode there, but not with the unicode string type.) 
Another example is that we perhaps don't have to support every encoding 
out there.

So I would suggest the following things to do:

- get rid of Jani's play branch
- move trunk to branches/FIRST_UNICODE_IDEA
- put 5.2 in security fix only mode
- pht 5.3 in bug fix only mode
- start adding new features (traits, Ilia's scalar typehint patch, 
  output buffering things) to the new trunk cloned from 5.3.
- in the meanwhile, start working on patching in back Unicode support, 
  but in small steps. Exactly which things, and how we'd have to find 
  out. But I do think it needs to be a *core* language feature, and not 
  simply solved by extensions. We also need to make sure everybody 
  understands that Unicode isn't just about encodings, or charsets and 
  that thre are differences between that. Education is going to be 
  important (and adding Unicode back in small bits would certainly help 
  there).

As I now have plenty of time to work on things, I'd be happy to act as 
RM, and wouldn't mind working on roadmaps and sorting out what good bits 
we have/had, and which things we don't want to port back into the new 
trunk. Depending on how things go, this could become 5.4 or 6 or 
something else.

with kind regards,
Derick

-- 
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug