Rasmus Lerdorf wrote:
So yes, the only real customers for this full Unicode mode in PHP 6 are
going to be the folks that have full control over their servers and
their software which will likely limit it to hosted services and exclude
large PHP software packages that will necessarily need to be written to
be portable. That of course creates a split right down the middle and
makes code sharing harder, and maybe it won't work, but the hope is we
can minimize these issues enough that the amount of code that
realistically needs to be written twice will be rather limited. If we
can't get it down to a manageable set of known things that people need
to watch out for, then our full unicode attempt has failed and we need
to stick with the half-assed approach. I'm not convinced we are there
yet and I'd hate to see us give up before we have taken a decent stab at
it. We need to think big and longterm, not small and shortterm here.
To me it boils down how we want to maintain the "fork":
1) PHP5 and PHP6
2) PHP6 unicode off/on (with PHP5 in maintenance mode)
Considering that people will not jump on PHP6 immediately anyways, I
think 1) is more realistic, if we make best efforts to back port new
features to PHP5, but still require that new features go into PHP6
first. Some features might not get back ported and that is a somewhat
unfriendly nudge towards PHP6. So it goes.
This way the PHP6 code base stays lean and people can realistically code
against PHP6. Hosters will hopefully offer both PHP5 and PHP6. I doubt
that many hosters would be interested in offering 3 versions at once
(PHP5, PHP6 unicode on/off).
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
