> -----Original Message----- > From: Pierre [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 19, 2007 9:09 AM > To: Rasmus Lerdorf > Cc: Peter Brodersen; internals@lists.php.net > Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6? > > 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. > > Cheers, > --Pierre
I remember when PHP 5 came out. All the apps I worked on and any I saw that was worth its salt took very little effort to get working in the new PHP version. The BC breaks weren't that bad. With that said, PHP 5 adoption was ... slow, at best. unicode.semantics is not the way to solve this problem in PHP 6. The big push for PHP 6 is UNICODE SUPPORT. And you're making this a switch that you can simply turn on and off? That's not how you move people onto the new version, that's how you keep people AWAY from it. Vendors are not going to be bothered to update their products to support PHP 6 with unicode on and off. And if they only write it one way or the other, they'll lose sales because it won't work on Customer A, B, and C's hosts. So, what will they do? Stay in stable waters for as long as they can. Which means, nobody's leaving PHP 4 or 5. PHP can afford a BC break, trust me. If you want people to adopt PHP 6, don't make it harder for them to do so. unicode.semantics does NOT make it easier for the vendors (who control PHP adoption, by the way -- it's all about who's programming the products for the versions) to adopt PHP 6. It makes it harder. You say you want to move people onto PHP 6 as seamlessly as possible by making it easy to port code written in PHP 5 onto it, and that's great. But, it's not the correct solution. Because, these people will have to live with the knowledge that their code "works on PHP 5, and on SOME distributions of PHP 6". You want people off of PHP 4 and PHP 5? Put together a plan to drop ALL support for these versions and PUBLICIZE the heck out of it. You let people KNOW that after PHP 6 is out, you have a steady plan to drop support for PHP 4 in x number of months and PHP 5 in x number of years(?). That way, if they want to continue getting security updates, they know where to go. And vendors will be more inclined to get their butts in gear to support updates in technology. In this situation, BC is going to be the bane of PHP's existence. By enabling unicode.semantics, you are polluting what PHP 6 was supposed to be and giving an excuse to people who are lazy and don't want to do the extra work necessary to support the changes. And those people will not do them, if you don't force them to. Meaning, their apps will work on PHP 5 and a subset of PHP 6 installations. But, let's look at this situation from another angle. What if unicode.semantics becomes the next magic_quotes or safe_mode, and is ALWAYS OFF in 95%+ of PHP installations? All of the work you did to add unicode support was WASTED on this presumption that if you don't have BC, no one's going to use it. Whereas the opposite is clearly true, in this case. If you have BC, it'll get used simply because it works with old code, but the main thing that changed about the language will never be touched. -- Jeremy Privett PHP Developer Zend Certified Engineer Peak8 Solutions -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
