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