Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:47272
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain zmievski.org from 209.85.212.42 cause and error)
Message-ID: <4B9CFE8E.7060403@zmievski.org>
Date: Sun, 14 Mar 2010 11:19:42 -0400
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: Derick Rethans <derick@php.net>
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, 
 PHP Developers Mailing List <internals@lists.php.net>
References: <4B9926E8.4080202@lerdorf.com> <alpine.DEB.2.00.1003131123540.4153@kossu.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.00.1003131123540.4153@kossu.derickrethans.nl>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 6
From: andrei@zmievski.org (Andrei Zmievski)

On 3/13/10 11:57 AM, Derick Rethans wrote:
> 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.
>    
FWIW, +1

Clearly, the current implementation is too difficult for people to work 
with. I still think that the major principles it was built on apply, but 
if people want to do a more lightweight approach that still uses those 
principles, I'm not going to be in the way.

-Andrei