Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:31779 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34329 invoked by uid 1010); 21 Aug 2007 08:49:00 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 34313 invoked from network); 21 Aug 2007 08:49:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Aug 2007 08:49:00 -0000 Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 85.10.196.195 serveforce1.backendmedia.com Linux 2.6 Received: from [85.10.196.195] ([85.10.196.195:36898] helo=serveforce1.backendmedia.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id F5/E0-28162-BF6AAC64 for ; Tue, 21 Aug 2007 04:49:00 -0400 Received: from soitgoes.local (cust.static.84-253-51-151.cybernet.ch [84.253.51.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by serveforce1.backendmedia.com (Postfix) with ESMTP id E77F4122460A; Tue, 21 Aug 2007 10:34:28 +0200 (CEST) Message-ID: <46CAA287.5080102@pooteeweet.org> Date: Tue, 21 Aug 2007 10:29:59 +0200 User-Agent: Thunderbird 2.0.0.6 (Macintosh/20070728) MIME-Version: 1.0 To: Andi Gutmans CC: Derick Rethans , Andrei Zmievski , Antony Dovgal , Rasmus Lerdorf , PHP Developers Mailing List References: <1181829227.3478.3.camel@localhost.localdomain> <468E1158.2030900@lerdorf.com> <468E13C6.1070109@pooteeweet.org> <468E2009.9000703@zend.com> <10845a340707060432h6516ea5eja0995dbc974baa0a@mail.gmail.com> <468E2A9C.8030704@zend.com> <10845a340707060454t24a854dfu93aad454dd1f37ed@mail.gmail.com> <468E2F78.9090002@pooteeweet.org> <10845a340707060509u70152abctf1801324be490ed1@mail.gmail.com> <468E400E.6060005@e-novative.de> <698DE66518E7CA45812BD18E807866CE92D7B0@us-ex1.zend.net> <698DE66518E7CA45812BD18E807866CE92D7E2@us-ex1.zend.net> <698DE66518E7CA45812BD18E807866CE92D7E6@us-ex1.zend.net> In-Reply-To: <698DE66518E7CA45812BD18E807866CE92D7E6@us-ex1.zend.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information X-backendmedia-com-MailScanner: Found to be clean X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=0, required 6) X-backendmedia-com-MailScanner-From: mls@pooteeweet.org X-Spam-Status: No Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6? From: mls@pooteeweet.org (Lukas Kahwe Smith) Andi Gutmans wrote: > Maybe you guys can try with ezComponents? So whats your target with this BC flag .. make it possible to have PHP4-PHP6 (unicode off) apps? Keep in mind that the camp that is suggesting to remove the unicode flag is at the same time committing to back porting more things to PHP5 in a case per case basis. As a result users will not be left in the dust with PHP5. Derick also suggested on IRC that we should focus on making PHP 5.3 as much forward compatible as possible, to make this even more feasible. Remember that several people have pointed out that maintaining the unicode flag is more or less like maintaining two branches (in some respects its even harder .. in some other its less .. which probably evens out more or less ..). At the same time we will need to maintain PHP5 for quite some time anyways as PHP6 matures and people get more RAM :) This porting effort will undoubtly benefit PHP6 in the ways you describe. It will help us find issues, it will help us improve the migration documentation. However binding this decision to actually porting a BIG PHP4 and a BIG PHP5 app is not feasible. We _know_ the increased effort in maintance, we do not know the performance impact and the migration time. So how can the default be that we increase the maintance effort in order to speed up something we do not know? regards, Lukas