Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:86541 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 82539 invoked from network); 10 Jun 2015 09:12:53 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 10 Jun 2015 09:12:53 -0000 Authentication-Results: pb1.pair.com smtp.mail=php.lists@allenjb.me.uk; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=php.lists@allenjb.me.uk; sender-id=pass Received-SPF: pass (pb1.pair.com: domain allenjb.me.uk designates 85.119.82.103 as permitted sender) X-PHP-List-Original-Sender: php.lists@allenjb.me.uk X-Host-Fingerprint: 85.119.82.103 server2.alteredperspective.co.uk Received: from [85.119.82.103] ([85.119.82.103:59929] helo=mail.apserver.co.uk) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id CC/73-61871-19FF7755 for ; Wed, 10 Jun 2015 05:12:51 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.apserver.co.uk (Postfix) with ESMTP id 11F0B2EC019; Wed, 10 Jun 2015 10:16:41 +0100 (BST) Received: from mail.apserver.co.uk ([127.0.0.1]) by localhost (server2.alteredperspective.co.uk [127.0.0.1]) (amavisd-new, port 10024) with LMTP id tNuiCcX3WYZA; Wed, 10 Jun 2015 10:16:37 +0100 (BST) Received: by mail.apserver.co.uk (Postfix, from userid 81) id 72CC42EC018; Wed, 10 Jun 2015 10:16:36 +0100 (BST) To: Nikita Popov X-PHP-Originating-Script: 501:rcube.php MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 10 Jun 2015 10:16:35 +0100 Cc: Stanislav Malyshev , Yasuo Ohgaki , Matt Wilmas , Christoph Becker , internals@lists.php.net In-Reply-To: References: <5576051A.3040800@gmx.de> <55760771.6020802@gmail.com> <778F345F9918474AB8CAAB03082ECBF7@pc1> <5577DEE4.8030205@gmail.com> Message-ID: X-Sender: php.lists@allenjb.me.uk User-Agent: Roundcube Webmail/1.1.1 Subject: Re: [PHP-DEV] Array dereferencing of scalars From: php.lists@allenjb.me.uk (AllenJB) On , Nikita Popov wrote: > On Wed, Jun 10, 2015 at 8:53 AM, Stanislav Malyshev > > wrote: > >> Hi! >> >> > > > $foo = 42; >> > $foo['bar']; // => NULL >> > $v = NULL; >> > $v[0][1][2][3][4][5][6][7][8][9]; // NULL >> > >> > this code is semantically wrong and I would like to have error/exception >> > for such >> > erroneous codes. It's inconsistent with array object, too. >> >> Why it's wrong? You try to get that's something not there, you get >> NULL. >> I don't see anything wrong. Adding fatal error about every little >> thing >> that isn't as expected never was how PHP worked. > > > I agree with what other people have said here: We should keep the > behavior > for NULL, but drop the nonsense for other types - (42)[24] not throwing > a > notice is quite ridiculous, that seems like a pretty obvious bug to me. > > Nikita PHP raises a notice when attempting to access properties on null. Surely it should be consistent and also raise a notice for array access on null? Array access on null is still a potential bug in the developers code. In addition to trying to avoid breaking existing code, I chose a notice for my PR ( https://github.com/php/php-src/pull/1269 ) because it's consistent with the behaviour of property access on non-objects, and also allows developers who wish to use a looser style to simply disable notices. I personally don't believe raising an error or EngineException in this case would fit with the way people expect PHP to work (in addition to causing an unnecessary BC break). If an EngineException is introduced for this, I believe a notice / deprecation must be issued first (even if current behaviour is undefined) to allow developers time and adequate notification to change their code. To answer an earlier query, my PR does raise multiple notices for deep-access (as in the last example given above). This is consistent with the behaviour on deep-property access on scalars/null. AllenJB