Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:30994
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 212.112.227.169 cause and error)
Message-ID: <469C6436.2060009@pooteeweet.org>
Date: Tue, 17 Jul 2007 08:39:50 +0200
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Andi Gutmans <andi@zend.com>
Cc: Ilia Alshanetsky <ilia@prohost.org>, jani.taskinen@iki.fi,
	internals@lists.php.net
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>
In-Reply-To: <698DE66518E7CA45812BD18E807866CE648290@us-ex1.zend.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] POSIX regex
From: mls@pooteeweet.org (Lukas Kahwe Smith)

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