Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:30180 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 17517 invoked by uid 1010); 14 Jun 2007 15:10:11 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 17491 invoked from network); 14 Jun 2007 15:10:11 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Jun 2007 15:10:11 -0000 Authentication-Results: pb1.pair.com header.from=tokul@users.sourceforge.net; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=tokul@users.sourceforge.net; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain users.sourceforge.net from 213.197.162.99 cause and error) X-PHP-List-Original-Sender: tokul@users.sourceforge.net X-Host-Fingerprint: 213.197.162.99 avilys.eik.lt Linux 2.6 Received: from [213.197.162.99] ([213.197.162.99:46557] helo=avilys.eik.lt) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CA/F0-08628-D4A51764 for ; Thu, 14 Jun 2007 11:10:08 -0400 Received: from avilys.eik.lt (avilys.local [127.0.0.1]) by avilys.eik.lt (Postfix) with ESMTP id 3AA6F1F5160 for ; Thu, 14 Jun 2007 18:08:21 +0300 (EEST) Received: from avilys.eik.lt (avilys.local [127.0.0.1]) by avilys.eik.lt (Postfix) with ESMTP id 1ECB21F515F for ; Thu, 14 Jun 2007 18:08:21 +0300 (EEST) Received: from 78.61.224.253 (NaSMail authenticated user tomas@topolis.lt) by avilys.eik.lt with HTTP; Thu, 14 Jun 2007 18:08:21 +0300 (EEST) Message-ID: <41820.78.61.224.253.1181833701.squirrel@avilys.eik.lt> In-Reply-To: References: <1181829227.3478.3.camel@localhost.localdomain> Date: Thu, 14 Jun 2007 18:08:21 +0300 (EEST) To: internals@lists.php.net User-Agent: NaSMail/1.0 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: [PHP-DEV] What is the use of "unicode.semantics" in PHP 6? From: tokul@users.sourceforge.net ("Tomas Kuliavas") >> During Derick's talk about PHP 6 at PHP Vikinger, I started to wonder >> what exactly was the reasoning behind adding something like >> "unicode.semantics" option. Derick didn't remember, neither did I. >> >> Apparently it's another one of these "register_globals" or >> "magic_quotes_*" directives we'll remove in PHP 7? :D >> >> I mean, if PHP 6 is about unicode, why upgrade to PHP 6 and disable it? >> Just stay with PHP 5 then.. > > Apparently there is a certain amount of users (undefined/undefinable > masses) who like to use PHP6 new features (?) without unicode. The > arguments were about the incompatibilities (the zend fatal errors are > likely to cause more troubles :) and performance. > > I was one who likes to have a single mode: unicode. Changes made in PHP6 unicode_semantics=on are not backwards compatible with PHP4 and PHP5. Same scripts (for example, reading string in bytes) work in PHP4 and PHP5. They won't work in unicode_semantics=on. PHP6 places very strict checks on string variables. PHP script writers are not used to it. If developers have to maintain compatibility with PHP6 unicode_semantics=on, they will have to do that in separate code branch. PHP6 code will break with E_PARSE errors in older PHP installs. I don't like it, because I can't turn that thing off. Interpreter is trying to outsmart me without knowing my coding environment. If you need multibyte string support, you have mbstring extension. If you want unicode function and variable names, you should remember that they won't work in international coding environment. International developers must use something they all understand. It means ASCII and English function names. Will you understand purpose of the function, when function name is written in Russian, Chinese or Arabic? -- Tomas