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