Pierre wrote:
On 6/19/07, Rasmus Lerdorf <[EMAIL PROTECTED]> wrote:
But this is no different from writing code that will work on both PHP 5
and PHP 6. The only difference is that instead of checking for PHP 5
you will be checking for Unicode. Like I said, we don't want the
Unicode decision to be synonymous with PHP 5 vs. PHP 6 because then the
non-Unicode folks will never get the benefits of the non-Unicode
improvements in PHP 6 and we would be forced to support PHP 5 for a lot
longer. We really stretch our already thing resources in order to
support multiple branches, so anything we can do to get as many people
as possible onto the same codebase helps us a lot.
Just as a last (hopefully) comment, even if nothing seemed to have an
influence, no matter how many we are to prefer a unicode only mode (so
far only you are in favour of it, maybe Andree too but I don't
remember his opinion on this topic :).
The gain we hope to have by keeping a non unicode mode is about having
more users moving to PHP6. I would like to know why it will work
better than with php5, any thoughts?
And let forget that maintaining (and develop/implement) these two
modes will obviously take more time.
I agree, we tried out best in PHP5 to provide support for PHP4 and it
seems this has not been overly successful. Why will this be any easier
for PHP6? Maybe we should try a different approach. Lets not hold
ourselves back. Lets break BC where it makes sense. Projects like PEAR
etc. could always claim that its also PHP5 compatible without truly
moving over. If we make a clean cut, this will not work anymore and
instead we have an opportunity to clean up, improve performance a bit by
removing unicode off hacks and let users migrate or stay. Sooner or
later they will be attracted by new shiny stuff and then they will make
a true effort to migrate over instead of these half migrations that
happened with PHP5 "adoption".
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
