> -----Original Message----- > From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 21, 2007 1:30 AM > To: Andi Gutmans > Cc: Derick Rethans; Andrei Zmievski; Antony Dovgal; Rasmus Lerdorf; PHP > Developers Mailing List > Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6? > > Andi Gutmans wrote: > > > Maybe you guys can try with ezComponents? > > So whats your target with this BC flag .. make it possible to have > PHP4-PHP6 (unicode off) apps?
It means having to only maintain one code base and also making it easier for people to adopt PHP 6 (Unicode isn't everything we'd have there). It also gives users the choice between Unicode PHP (which will be a headache for some) and the easy PHP. Also performance is something which I think is important but we don't know the full impact yet. If it's just 20% it's not a big deal; if it's much more than it probably is. Also memory usage is a big issue today with scalable Web apps. > Keep in mind that the camp that is suggesting to remove the unicode > flag > is at the same time committing to back porting more things to PHP5 in a > case per case basis. As a result users will not be left in the dust > with > PHP5. Yes, this is definitely a good idea but it'd require more maintenance mode because we'd have to maintain it for much longer. That said it's probably the best alternative. > > Derick also suggested on IRC that we should focus on making PHP 5.3 as > much forward compatible as possible, to make this even more feasible. Yes, definitely. For starters we should have the (binary) cast operator there. > Remember that several people have pointed out that maintaining the > unicode flag is more or less like maintaining two branches (in some > respects its even harder .. in some other its less .. which probably > evens out more or less ..). At the same time we will need to maintain > PHP5 for quite some time anyways as PHP6 matures and people get more > RAM :) This isn't quite true. You will have to maintain two code paths in all internal functions anyway because you will support both UTF-16 and binary strings. The biggest problems are in the engine and most of the maintenance has been done by us. So it's not going to affect most people. > This porting effort will undoubtly benefit PHP6 in the ways you > describe. It will help us find issues, it will help us improve the > migration documentation. However binding this decision to actually > porting a BIG PHP4 and a BIG PHP5 app is not feasible. We _know_ the > increased effort in maintance, we do not know the performance impact > and > the migration time. So how can the default be that we increase the > maintance effort in order to speed up something we do not know? I think that we are having this discussion based on very little data. People here are saying that the upgrade path is quite easy. We've had very different experiences. I'd like some more time to look into that and see if we can make automated scripts to help people convert (like we did from php/fi 2 to php 3). It'd also shed some more light onto the performance piece and see if it truly is significant. Btw, not sure why the maintenance piece is being discounted so much. I still think that PHP 6 with two modes is less maintenance efforts than PHP 5 and PHP 6 for many more years. At least we stick to one code base even if the modes aren't compatible. In that sense it would be no different from just PHP 5 and PHP 6. Anyway, I am listening. I will try and help find some data points and hopefully find an acceptable solution but this takes some time. Which is why I said that if part of the community helped in figuring some of this out it'd be great. Andi
