Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:30257 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31937 invoked by uid 1010); 19 Jun 2007 15:20:37 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 31907 invoked from network); 19 Jun 2007 15:20:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Jun 2007 15:20:37 -0000 Authentication-Results: pb1.pair.com header.from=mls@pooteeweet.org; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=mls@pooteeweet.org; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 212.112.227.169 cause and error) X-PHP-List-Original-Sender: mls@pooteeweet.org X-Host-Fingerprint: 212.112.227.169 ipx11223.ipxserver.de Linux 2.5 (sometimes 2.4) (4) Received: from [212.112.227.169] ([212.112.227.169:43559] helo=ipx11223.ipxserver.de) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6E/3C-47650-044F7764 for ; Tue, 19 Jun 2007 11:20:35 -0400 Received: from localhost (localhost [127.0.0.1]) by ipx11223.ipxserver.de (Postfix) with ESMTP id 844DCDF00FE; Tue, 19 Jun 2007 17:20:28 +0200 (CEST) Received: from ipx11223.ipxserver.de ([127.0.0.1]) by localhost (flottensignalgeber [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02014-01; Tue, 19 Jun 2007 17:20:26 +0200 (CEST) Received: from [127.0.0.1] (234.24.3.213.fix.bluewin.ch [213.3.24.234]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ipx11223.ipxserver.de (Postfix) with ESMTP id E8791DF009E; Tue, 19 Jun 2007 17:20:24 +0200 (CEST) Message-ID: <4677F3FA.3010000@pooteeweet.org> Date: Tue, 19 Jun 2007 17:19:22 +0200 User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 To: Pierre Cc: Rasmus Lerdorf , Peter Brodersen , internals@lists.php.net References: <1181829227.3478.3.camel@localhost.localdomain> <7d5a202f0706141844l3c75b556hdbecbcd5a43747c9@mail.gmail.com> <4671F184.2020401@lerdorf.com> <6sof73dj69ldpspfc5ukrc58qr9ckbin2b@4ax.com> <4677E7B1.2080305@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by somedaemon at backendmedia.com Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6? From: mls@pooteeweet.org (Lukas Kahwe Smith) Pierre wrote: > On 6/19/07, Rasmus Lerdorf wrote: > >> But this is no different from writing code that will work on both PHP 5 >> and PHP 6. The only difference is that instead of checking for PHP 5 >> you will be checking for Unicode. Like I said, we don't want the >> Unicode decision to be synonymous with PHP 5 vs. PHP 6 because then the >> non-Unicode folks will never get the benefits of the non-Unicode >> improvements in PHP 6 and we would be forced to support PHP 5 for a lot >> longer. We really stretch our already thing resources in order to >> support multiple branches, so anything we can do to get as many people >> as possible onto the same codebase helps us a lot. > > Just as a last (hopefully) comment, even if nothing seemed to have an > influence, no matter how many we are to prefer a unicode only mode (so > far only you are in favour of it, maybe Andree too but I don't > remember his opinion on this topic :). > > The gain we hope to have by keeping a non unicode mode is about having > more users moving to PHP6. I would like to know why it will work > better than with php5, any thoughts? > > And let forget that maintaining (and develop/implement) these two > modes will obviously take more time. I agree, we tried out best in PHP5 to provide support for PHP4 and it seems this has not been overly successful. Why will this be any easier for PHP6? Maybe we should try a different approach. Lets not hold ourselves back. Lets break BC where it makes sense. Projects like PEAR etc. could always claim that its also PHP5 compatible without truly moving over. If we make a clean cut, this will not work anymore and instead we have an opportunity to clean up, improve performance a bit by removing unicode off hacks and let users migrate or stay. Sooner or later they will be attracted by new shiny stuff and then they will make a true effort to migrate over instead of these half migrations that happened with PHP5 "adoption". regards, Lukas