Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31044
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: <469DE3A0.1060902@pooteeweet.org>
Date: Wed, 18 Jul 2007 11:55:44 +0200
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: Rasmus Lerdorf <rasmus@lerdorf.com>
Cc: Derick Rethans <derick@php.net>,
	PHP Developers Mailing List <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> <fe05d1540707170021y423f7d81kd1ab28a5719630fb@mail.gmail.com> <7.0.1.0.2.20070718023255.0dc0eed0@zend.com> <alpine.DEB.0.98.0707181014230.10300@kossu.ez.no> <469DE09F.9080509@lerdorf.com>
In-Reply-To: <469DE09F.9080509@lerdorf.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] POSIX regex
From: mls@pooteeweet.org (Lukas Kahwe Smith)

Rasmus Lerdorf wrote:
> Derick Rethans wrote:
>> Regarding the unicode on/off modes, I don't think you put yourself in 
>> the developer's view at all. Users are not going to be better of having 
>> to deal with both modes.
> 
> Have you guys really thought this through?
> 
> Let's look at this from two angles.
> 
> First, from the our perspective maintaining and developing PHP.  Without
> the Unicode switch, and as has already been suggested, PHP 5 will never
> die.  Anything new in PHP 6 that isn't related to Unicode will be
> backported to PHP 5.  Or, a slight variation of that, any developer with
> no interest in Unicode will only work on the PHP 5 branch and not bother
> worrying about whether it works in PHP 6 forcing others to do that work.
>  I don't think we have the resources to do this, and I think it is
> likely to either create 2 classes of developers and potentially
> diverging trees, or it may simply kill off the Unicode effort altogether
> if not enough developers bother looking at PHP 6 since PHP 5 will live
> forever and is free of all this annoying Unicode stuff that is just too
> complicated to deal with.
> 
> Second, from the user space PHP developers' perspective.  There are two
> groups of those out there.  There is the group that builds apps for
> controlled environments.  Yahoo, Facebook, and the hundreds, if not
> thousands of smaller companies out there that will define a certain PHP
> configuration and code against that.  To them such a switch isn't a big
> deal except when it comes to re-using external code.  Which bring us to
> the second group which is the group that strives to build portable apps
> designed to run on as many unknown PHP configs as possible.  This is the
> group that will get hit by this, and here is where we need to figure out
> how to cause them the least amount of pain.  They are going to feel some
> pain in order to get their heads around Unicode no matter how we handle
> this.  For the portion of these folks who don't want to worry about
> Unicode at all and they actually have code that does stuff on binary
> strings that will break, their stuff just won't work no matter what we
> do.  The difference comes down to whether it gets marked as PHP5-only or
> it gets marked as non-Unicode-only.  And the other camp who do want to
> make sure their stuff supports Unicode will need to write the Unicode
> and non-Unicode versions and check to see if the system they are running
> on supports Unicode or not.  Whether they check the PHP version number,
> or the Unicode switch, or probe directly for the features they need, it
> ends up being about the same amount of pain.
> 
> What may be somewhat lost in all this, that I hope nobody here is
> forgetting, is that smooth Unicode support is really important.  Being
> able to work directly in your native charset with your native strings
> without having to deal with iconv and other crap is the goal here.  And
> let's also not forget that a lot of code will actually work unchanged in
> PHP 6 Unicode-mode and suddenly be Unicode-capable where they weren't
> before.  I would love to see all this energy put toward making sure as
> much code as possible falls into this category instead of arguing about
> where to put the Unicode switch.  It's still a switch whether you put it
> in the version number or in the .ini file.  In the version number it is
> simply easier for people to ignore from all sides or the discussion
> here, but where does that leave us 4 years from now?

I guess the question (which I am unable to answer) is if its easier to 
maintain PHP6 with the switch or be forced to backport to PHP5 without 
the switch in PHP6. If it does end up that a lot of devs prefer to work 
on PHP5 and as a result PHP6 is left dangling, I wonder if with the 
switch things will be any easier as devs will work/test only the non 
unicode side of things? I think this was the key point that was brought 
up that it will not be easier and instead was deemed more error prone to 
handle all the if's in a single tree, versus have a "clean" separation.

Also I wonder how a unicode on/off switch will be handled on the 
documentation side. It would add more permutations in the documentation 
to have the switch. From my understanding the situation is fairly non 
trivial already in how to handle all the version dependent differences. 
Philipp, whats your take on this?

regards,
Lukas