Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:29870 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70201 invoked by uid 1010); 29 May 2007 15:24:54 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 70186 invoked from network); 29 May 2007 15:24:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 May 2007 15:24:54 -0000 Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.162.235 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 64.233.162.235 nz-out-0506.google.com Linux 2.4/2.6 Received: from [64.233.162.235] ([64.233.162.235:63042] helo=nz-out-0506.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id D1/EB-08609-4C54C564 for ; Tue, 29 May 2007 11:24:54 -0400 Received: by nz-out-0506.google.com with SMTP id 34so1100237nzf for ; Tue, 29 May 2007 08:24:50 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KV/NO0bTtUwe7J3RYkknSvn6J+RmKpipy3dZbOCTMVvGB29byGqo5mcbRlxmJV96ZsLPRkeqjK2sA6s9syedUyKqF8rxjtdVaf/7xgT3XwshVCNW4xOsLLmxwrPAy0srd8ihKPEYlzsXq4EvbipSt7JfLZII+qe3NX/CD1tAY30= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c3VXEVlHEu3LndNLktkMYexm6EKxEEH2lhpDleelSCWFhB786zm9u7cWgAdScMatkj+gbE4AlCxlTGPZ6k2MF5c2HPBrlktHIXcvnnJ4azRCP2JaZS1HzWYoaZAk1fpecN9CEKWc+qGberEBvMK3R6+L/pE9uN2XlBcd8L1/rWc= Received: by 10.114.132.5 with SMTP id f5mr3441065wad.1180452289916; Tue, 29 May 2007 08:24:49 -0700 (PDT) Received: by 10.114.178.2 with HTTP; Tue, 29 May 2007 08:24:49 -0700 (PDT) Message-ID: Date: Tue, 29 May 2007 17:24:49 +0200 To: "David Coallier" Cc: "Antony Dovgal" , php-dev In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <465BF195.2080300@zend.com> Subject: Re: [PHP-DEV] bitwise operations and Unicode strings From: pierre.php@gmail.com (Pierre) Hi, On 5/29/07, David Coallier wrote: > On 5/29/07, Antony Dovgal wrote: > > Hello. > > > > Do you think the engine should support bitwise operators and Unicode strings? > > If yes, how do you think it should work? > > > > Example: > > > $a = "1"; > > $a|="2"; > > var_dump($a); > > ?> > > > > This code outputs "3" in native mode and "Fatal error: Unsupported operand types" in Unicode mode. > > I believe this is an inconsistency and it should be possible to use Unicode strings there. > > Definitely > > > > > There are several possible ways to implement it: > > 1) the same as with native strings - apply the operator to each element of the string separately; > > 2) convert the string to binary (using say iso-8859-1) and then see 1); > > I would probably be for the solution #2 and of course using the > unicode.runtime_encoding ini setting to convert it to binary. > > > > > > We can also leave it as is (since it doesn't seem very useful) or even drop the native strings support (it doesn't seem very useful to me either). > > I think this is a bad choice.. might not be useful to you, but might > be to some other people I fail to see or imagine any useful usages for such hacks. Laziness justifies it with binary strings (as in 5.x), but as long as an unicode string is given, one should really first cast to integer before using it with a bitwise operator (or any other non string operation). I'm in favour of keeping the current behaviors and drop the native support as well for consistency (and documentation/wtf headaches). --Pierre