Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:70267 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67156 invoked from network); 21 Nov 2013 19:49:47 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 21 Nov 2013 19:49:47 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 108.166.43.67 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 108.166.43.67 smtp67.ord1c.emailsrvr.com Linux 2.6 Received: from [108.166.43.67] ([108.166.43.67:49766] helo=smtp67.ord1c.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 1B/45-36839-9D36E825 for ; Thu, 21 Nov 2013 14:49:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 5A9B01482B9; Thu, 21 Nov 2013 14:49:42 -0500 (EST) X-Virus-Scanned: OK Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id C3F8B148233; Thu, 21 Nov 2013 14:49:41 -0500 (EST) Message-ID: <528E63D5.6090908@sugarcrm.com> Date: Thu, 21 Nov 2013 11:49:41 -0800 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: Yasuo Ohgaki CC: "internals@lists.php.net" References: <528D2E66.7090009@ajf.me> <528D2F4D.6050003@ajf.me> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] fix bug #53432 (Assignment via string index access on an empty string converts to array) From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I've added this behavior to RFC (NOT for voting) > https://wiki.php.net/rfc/comparison_inconsistency?&#conversioncomparison I'm not sure behavior that is documented and implemented exactly as it was planned (e.g. min() behavior) can be called "inconsistency". It is actually completely consistent and does exactly what it is meant to do. Same for dec/hex strings - it works exactly like strtod(). Of course it does not support every numeric base in existence, but it was never supposed to. Also, "Null string is not handled as string" is not correct - null string is handled as string, except in one narrow case where you apply array operations to it. Right now it gives an impression empty strings are not handled as strings in PHP at all, which is not correct. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227