Non-core PHP developer speaking, so read with that in mind: One of the things that held back PHP 5 adoption for so long, IMO, is the large amount of FUD that surrounded it. Even now, 3 years after it was released, I keep seeing the argument that "I can't drop PHP 4 and use PHP 5, then I have to rewrite *everything* to use objects. I hate objects." That is, of course, completely untrue, and if you're paying even moderate attention it's not at all difficult to write code that runs just fine in both PHP 4 and PHP 5, with and without register_globals and magic_quotes. All it takes is a little forethought and not letting yourself be sloppy.
Writing PHP 5/6 compatible code needs to be just as easy, if not easier, in addition to having better marketing to head off the FUD. Taking a stance of "you'll have to start from scratch if you want to be PHP 6 compatible, oh well" is an absolutely sure-fire way to guarantee that no one uses PHP 6 for anything except niche markets. If people are still relying on register_globals at this point, sure, they're screwed no matter what they do. But code written to PHP 5 E_STRICT standards with a recommended configuration (register_globals off, etc.) should be possible to make run successfully in PHP 6 without gutting and starting from scratch (even if you can't use the new-and-cool features). If not, "GoPHP6" will be a failure before it even gets started. :-) (And yes, I'm already pondering how to do GoPHP6 in order to make the 5/6 transition smoother.) On Monday 16 July 2007, Andi Gutmans wrote: > I disagree with this view of the world. > It doesn't have to be a complete either/or decision and labeling > everything as a "bc hacks" decision is an inacurrate and populistic way > of building FUD. > > There are clear things we want to change (like register_globals) because > we believe that ultimately they have a significant benefit to our users > with controllable downside (there is an easy one line workaround which > we can document for people to get their old apps to work). There are > other areas where breaking BC makes sense. But saying we should just > break it across the board and not even consider having a good upgrade > path for our users is unreasonable. I believe we can have a very good > PHP 6, which is pretty much in sync with many of your feelings, but that > provides a well documented and reasonable upgrade path (unlike VB -> > VB.NET). > > If you want to break everything and anything and don't want to be > limited whatsoever by our huge user-base then maybe you should write a > new language which fits exactly what your preference would be. The fact > is though, that even after these discussions and the Paris discussions, > the bulk of the idiosyncracies which make PHP what it is today will > remain (as per agreement). So there must have been some kind of view > even by the folks here that they don't want to create a new language but > improve on what we have. And it's a trade-off between bang for the buck; > sometimes it really brings high returns to break BC especially when it > comes to security; but sometimes except for making 10 PHP devs happy who > are not the bulk of our users it doesn't. > > So let's not oversimplify this situation. We have to continue to make > trade-offs. > > Btw, one of PHP's strengths has been in high performance sites and with > a Unicode=on only mode this would take quite a hit (but it's not the > only reason why I need we need choice). In any case, I think on this > question it does make sense that we start making "informed" decisions by > understanding the migration path better, as opposed to just basing > decisions on gut feelings. Maybe that kind of learning experience will > proove me wrong (which may be so). > > Andi > > > -----Original Message----- > > From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 16, 2007 7:25 AM > > To: Andi Gutmans > > Cc: Ilia Alshanetsky; [EMAIL PROTECTED]; internals@lists.php.net > > Subject: Re: [PHP-DEV] POSIX regex > > > > Andi Gutmans wrote: > > > Even in PHP 6 I am not sure it's a good idea. There are a > > > > huge amount > > > > > of apps that use them and it'll be very hard for people to upgrade. > > > Anyway, let's do some more research on that once we get > > > > closer to PHP > > > > > 6 and see what the migration path looks like. We'll have to > > > > check with > > > > > a few popular apps + google code search :) No need to > > > > decide on that > > > > > right now without having more info. > > > > I disagree with this approach. The thing is that we need to > > get a clear message out ASAP. This all ties into topics like > > if we will have a unicode off/on switch or not. Delaying > > these decisions will hurt our userbase. We need to prepare them early. > > > > IMHO we should use PHP6 as the clean up release. Drop unicode > > on/off switch, accept that the bulk of all code will need to > > be rewritten from scratch. The benefit will be that it will > > truely be cleaned up, people will still be able to leverage > > the bulk of their PHP programming background and they can > > enjoy the fastest possible unicode engine we can provide them. > > > > PHP5 will be for the people that cannot make the jump. We > > will back port whatever we can reasonably get into PHP5. > > People will linger on PHP5, just as they are doing now with > > PHP4. So it goes. At least we will not punish the early > > adopters for those that are unwilling to move to the new > > version in the near future anyways. > > > > At any rate .. the time is now to make a decision on what its > > gonna be. > > PHP6 with BC hacks or not. > > > > regards, > > Lukas -- Larry Garfield AIM: LOLG42 [EMAIL PROTECTED] ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
