Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:19499 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 61014 invoked by uid 1010); 7 Oct 2005 21:47:32 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 60998 invoked from network); 7 Oct 2005 21:47:31 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 7 Oct 2005 21:47:31 -0000 X-Host-Fingerprint: 69.56.217.178 unknown Linux 2.4/2.6 Received: from ([69.56.217.178:41456] helo=coggeshall.org) by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP id DD/37-54476-3FCE6434 for ; Fri, 07 Oct 2005 17:47:31 -0400 Received: from [192.168.1.69] (ool-4576ee05.dyn.optonline.net [69.118.238.5]) (authenticated bits=0) by coggeshall.org (8.12.8/8.12.8) with ESMTP id j97KEcF9020682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 7 Oct 2005 15:14:39 -0500 To: Rasmus Lerdorf Cc: Derick Rethans , PHP Developers Mailing List In-Reply-To: <4346E3F2.30904@lerdorf.com> References: <99dd4f75f4ceebfe1c980cf439e97416@gravitonic.com> <4346E00A.8020504@prohost.org> <4346E0C5.3090001@lerdorf.com> <4346E3F2.30904@lerdorf.com> Content-Type: text/plain Date: Fri, 07 Oct 2005 17:47:14 -0400 Message-ID: <1128721634.26042.169.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-6) Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Unicode Implementation From: john@coggeshall.org (John Coggeshall) On Fri, 2005-10-07 at 22:09 +0100, Rasmus Lerdorf wrote: > The "don't upgrade" argument doesn't work. Unless we commit to having > two major versions forever where we will add new features. That is a > possibility as well of course. Have 2 trees. Unicode-PHP and > non-Unicode-PHP and everything that is not Unicode-related will need to > be committed to both. I think this would lead to PHP 6.2 with two different sets of functionality (Joe writes some super-string-manipulating thing for PHP 6.2, never find the time to port it to 6.2-unicode, and now no one else has time to do it either so we release one with the function, one without yet they are both 6.2). While I understand the argument that PHP itself will be slower with Unicode support, and there isn't much we can do about that (we're just doing a heck of a lot more work across the board), I think the best option is to have PHP 6 be completely Unicode. It will break applications, but they can be ported. It will mean PHP is going to be slower, but other languages have found ways to make up for that speed decrease in other places and I am sure we could learn from looking at them for answers to our problem. Cheers, John