I very much agree with Rasmus that giving our users the option is extremely valuable.
Unicode support is useful to some people but I think it's a mistake to force it down everyone's throat. Forget the fact that it will be considerably slower and eat up more memory than PHP 5 & 4, but there will also be some serious BC issues and idiosyncrasies which a huge part of our community (arguably over 90%) just don't care about. Some people here said that we weren't successful in keeping BC between PHP 5 and PHP 4. Whoever said that must not have migrated applications between the versions. It took very little effort to do so. Most people I know did it in a matter of hours for sizeable code bases and in fact most time was spent on regression testing which would need to be done anyway. I also think that the fact that we *do* still support PHP 4 is a strength and not a weakness of the PHP project (as much as I'd like everyone to migrate to PHP 5). Sure maybe that gave less incentive to upgrade which is a bit of a PITA for the PHP eco-system. On the other hand look at technologies who didn't do that. Microsoft with VB, DNA, DCOM and some of their other technologies are good examples. Every version their users would suffer time and time again, often having to completely migrate their investment because they were not officially supported anymore. Look at how Microsoft are looking to ditch XP early in the process. I don't think we want to follow that path. The fact that we do our best not to break BC and are very careful when doing it is a HUGE plus for us. Not to mention still doing security and critical fixes for PHP 4. Btw, on the "if (UG(unicode)" issue. That's really a bunch of BS. There'll be no problems once we get into optimizing Unicode mode to make sure we take good advantage of CPU branch predicition (with compilers help). We are intentionally not trying to do premature optimizations right now but rather make sure we get the end result that we want from a functionality point of view, and the optimize according to what the real bottlenecks are. I have always been against premature optimizations and I can pretty much promise that the "if (UG(unicode))" is not going to be an issue. It's a bit more code yes. But I think it's worth it. We had a lot of discussions on this issue within the core development team and I think there was a strong enough case to keep things this way. If we are proven wrong down the road then there's always PHP 6.5 or 7 where we can nuke the 8bit mode. But my guess is that at least 80%+ of PHP 6 users will not run in Unicode mode. For many there's just not sufficient reason to do so. Andi > -----Original Message----- > From: Rasmus Lerdorf [mailto:[EMAIL PROTECTED] > Sent: Tuesday, June 19, 2007 9:05 AM > To: Jeremy Privett > Cc: internals@lists.php.net > Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" > in PHP 6? > > Jeremy Privett wrote: > > 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. > > I actually don't have a problem with 95% of PHP 6 > installations turning off Unicode support and this being the > default setting for ISP's. > > Full Unicode support in an application is a big commitment > and it will take quite a bit of work. I just don't think > that many people will invest the time and effort into doing > this, but at the same time there will be large applications > and services that have full control over their server > settings that will make use of it. Think Flickr, Yahoo, > Facebook, etc. > > If enough people think it is a good idea to remove the switch > we can do it, but we have to realize that everything we > improve in PHP 6 will mostly be for the benefit of these > large dedicated applications and the regular Joe User on a > shared server will never see these them. > > -Rasmus > > -- > PHP Internals - PHP Runtime Development Mailing List To > unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
