Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34872
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain gravitonic.com from 204.11.219.139 cause and error)
In-Reply-To: <47956F60.3050902@wikimedia.org>
References: <4794AE48.20005@daylessday.org> <47956F60.3050902@wikimedia.org>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-ID: <0DC2776D-F5A1-4C80-9408-8E5A29D833CD@gravitonic.com>
Cc: php-dev <internals@lists.php.net>
Content-Transfer-Encoding: 7bit
Date: Mon, 21 Jan 2008 20:25:06 -0800
To: Tim Starling <tstarling@wikimedia.org>
Subject: Re: [PHP-DEV] why we must get rid of unicode.semantics switch ASAP
From: andrei@gravitonic.com (Andrei Zmievski)

> As for PHP 6 generally: there needs to be a solid migration path,  
> such as forwards-compatible syntax introduced to PHP 5. MediaWiki  
> has extensive support for unicode in PHP 5, including a pure PHP  
> implementation of NFC, cross-script and confusable character  
> checks, extensive parsing of UTF-8 text using regexes both with and  
> without /u, and megabytes of localisations in the form of PHP  
> source files with UTF-8 string literals.
>
> Porting all this to a UTF-16-based environment would be a hassle,  
> and we don't gain anything from it in terms of features for our  
> users. I'd hate to end up in an adversarial situation, where  
> developers working in PHP are forced to boycott or fork PHP 6.  
> That's why a simple migration path is important.
>

I don't think that "porting to a UTF-16 environment" in your case is  
that hard at all. UTF-8 source files will work transparently with  
proper script encoding setting, PCRE regexes work the same way, and  
you could replace your own implementations of NFC, etc with PHP  
provided ones.

-Andrei