Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:30997 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 30504 invoked by uid 1010); 17 Jul 2007 14:27:52 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 30489 invoked from network); 17 Jul 2007 14:27:52 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jul 2007 14:27:52 -0000 Authentication-Results: pb1.pair.com header.from=andi@zend.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=andi@zend.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender) X-PHP-List-Original-Sender: andi@zend.com X-Host-Fingerprint: 63.205.162.114 unknown Windows 2000 SP4, XP SP1 Received: from [63.205.162.114] ([63.205.162.114:40500] helo=us-ex1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 40/68-61397-2E1DC964 for ; Tue, 17 Jul 2007 10:27:51 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 17 Jul 2007 07:27:38 -0700 Message-ID: <698DE66518E7CA45812BD18E807866CE6483DF@us-ex1.zend.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PHP-DEV] POSIX regex Thread-Index: AcfIPVj+5hFRYTUVTnCMRPfhRDZALAAQC3+g References: <698DE66518E7CA45812BD18E807866CE648191@us-ex1.zend.net> <54C4340A-D9EA-4B5A-B39C-B55B29B1B3BC@prohost.org> <698DE66518E7CA45812BD18E807866CE648193@us-ex1.zend.net> <469B7FB1.1070507@pooteeweet.org> <698DE66518E7CA45812BD18E807866CE648290@us-ex1.zend.net> <469C6436.2060009@pooteeweet.org> To: "Lukas Kahwe Smith" Cc: "Ilia Alshanetsky" , , Subject: RE: [PHP-DEV] POSIX regex From: andi@zend.com ("Andi Gutmans") 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.=20 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=3Don. 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=3Doff. Btw, most languages deliver Unicode in this way and it works pretty well. Andi > -----Original Message----- > From: Lukas Kahwe Smith [mailto:mls@pooteeweet.org]=20 > Sent: Monday, July 16, 2007 11:40 PM > To: Andi Gutmans > Cc: Ilia Alshanetsky; jani.taskinen@iki.fi; internals@lists.php.net > Subject: Re: [PHP-DEV] POSIX regex >=20 > Andi Gutmans wrote: >=20 > > There are clear things we want to change (like register_globals)=20 > > because we believe that ultimately they have a significant=20 > benefit to=20 > > our users with controllable downside (there is an easy one line=20 > > workaround which we can document for people to get their=20 > old apps to=20 > > work). There are other areas where breaking BC makes sense.=20 > But saying=20 > > we should just break it across the board and not even=20 > consider having=20 > > a good upgrade path for our users is unreasonable. I believe we can=20 > > have a very good PHP 6, which is pretty much in sync with=20 > many of your=20 > > feelings, but that provides a well documented and=20 > reasonable upgrade=20 > > path (unlike VB -> VB.NET). >=20 > I never said we should break BC just for the hell of it. The=20 > goal must be that PHP6 feels and behaves like PHP. Its not=20 > about high-jacking PHP to come up with the language we all=20 > wanted instead. >=20 > > So let's not oversimplify this situation. We have to=20 > continue to make=20 > > trade-offs. >=20 > Sure, but you are suggesting to delay decisions indefinitely.=20 > Either you are saying this because you already decided that=20 > you don't want this change, or you are accepting that our=20 > users will be unable to prepare themselves for what happens=20 > in the future. This of course will make it that much harder=20 > for them to take the plunge into PHP6. >=20 > > Btw, one of PHP's strengths has been in high performance sites and=20 > > with a Unicode=3Don only mode this would take quite a hit=20 > (but it's not=20 > > the only reason why I need we need choice). In any case, I think on=20 > > this question it does make sense that we start making "informed"=20 > > decisions by understanding the migration path better, as opposed to=20 > > just basing decisions on gut feelings. Maybe that kind of learning=20 > > experience will proove me wrong (which may be so). >=20 > I have not seen any proposed way of finding out this=20 > migration path besides lets wait. Lets wait is not the=20 > answer. What I asked for was exactly a decision on how far we=20 > are willing to go with the breakage and more importantly the=20 > fundamental decision about how we approach unicode in PHP6.=20 > The on off switch is not something that makes sense to delay=20 > until forever. Its a big decision and once its decided other=20 > things will become much easier (like PHP6 development or=20 > deciding the impact of other potential BC breaks). >=20 > regards, > Lukas >=20