Just FYI: I did not agree with that choice. And IIRC, neither did several other people here.
--Jani On Tue, 2007-07-17 at 07:27 -0700, Andi Gutmans wrote: > A few months ago we agreed that we will give our users the choice of > both modes. The burdon of maintenance has mainly been on us btw as the > majority of the differences here are in the Zend Engine and the > extensions don't have as much work associated with them. > > Here's my proposed way of figuring how to make migration easier. Port > the following applications to PHP 6 and let's see what we can learn from > it: > - mediaWiki > - SugarCRM > - Drupal > - Wordpress > > I don't think we can have more of a reality check than actually going > through this exercise and understanding the issues. As I mentioned from > the small work we have done up to now it seems like there really is no > migration patch except for applications to be almost completely > rewritten when unicode_semantics=on. I don't think this is a feasible > way to go. But if volunteers can work on this porting and it allows us > to fix some things (if they are fixable) then that would change the > situation. > > I believe that people who actually do this exercise and want to have a > migration path will understand that there's no other way except to > support unicode_semantics=off. Btw, most languages deliver Unicode in > this way and it works pretty well. > > Andi > > > -----Original Message----- > > From: Lukas Kahwe Smith [mailto:[EMAIL PROTECTED] > > Sent: Monday, July 16, 2007 11:40 PM > > To: Andi Gutmans > > Cc: Ilia Alshanetsky; [EMAIL PROTECTED]; internals@lists.php.net > > Subject: Re: [PHP-DEV] POSIX regex > > > > Andi Gutmans wrote: > > > > > 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). > > > > I never said we should break BC just for the hell of it. The > > goal must be that PHP6 feels and behaves like PHP. Its not > > about high-jacking PHP to come up with the language we all > > wanted instead. > > > > > So let's not oversimplify this situation. We have to > > continue to make > > > trade-offs. > > > > Sure, but you are suggesting to delay decisions indefinitely. > > Either you are saying this because you already decided that > > you don't want this change, or you are accepting that our > > users will be unable to prepare themselves for what happens > > in the future. This of course will make it that much harder > > for them to take the plunge into PHP6. > > > > > 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). > > > > I have not seen any proposed way of finding out this > > migration path besides lets wait. Lets wait is not the > > answer. What I asked for was exactly a decision on how far we > > are willing to go with the breakage and more importantly the > > fundamental decision about how we approach unicode in PHP6. > > The on off switch is not something that makes sense to delay > > until forever. Its a big decision and once its decided other > > things will become much easier (like PHP6 development or > > deciding the impact of other potential BC breaks). > > > > regards, > > Lukas > > > > -- > 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
