Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87927
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain allenjb.me.uk designates 85.119.82.103 as permitted sender)
To: Sherif Ramadan <theanomaly.is@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Wed, 26 Aug 2015 11:33:43 +0100
Cc: Nicolai Scheer <nicolai.scheer@gmail.com>, PHP Internals
 <internals@lists.php.net>
In-Reply-To: <CAL+t6cH6tGonP2-ZNDv05Neo4X_5WGypYMnvUUPZMz-QnBFkxQ@mail.gmail.com>
References: <CAOg_pRR=2kJpEX8jSW13Xxy8x16GQR8casXxFJpYjXT1qUfVYA@mail.gmail.com>
 <CAL+t6cHfJWkk4pbUJ3E=5huytMNQmJ0Le=Mt4iSmyJ_cxOCbZg@mail.gmail.com>
 <e229310e01848a1e478c6f02e924aeeb@allenjb.me.uk>
 <CAL+t6cH6tGonP2-ZNDv05Neo4X_5WGypYMnvUUPZMz-QnBFkxQ@mail.gmail.com>
Message-ID: <9c8b50a1515099e54056473e0dc3fba5@allenjb.me.uk>
User-Agent: Roundcube Webmail/1.1.1
Subject: Re: [PHP-DEV] Notice on non existing array key (on a boolean)
From: php.lists@allenjb.me.uk (AllenJB)

I've added an explicit set of tests for object properties and function 
return values and they're passing for me (I also updated the branch to 
current master and updated the tests to handle Engine Exceptions).

The build passes on my branch, but 1 failed on the PR and I can see no 
way to request a retry without pushing "non-changes". The test failure 
appears completely unrelated. (I did notice that the failing build has a 
warning about running on legacy Travis infrastructure)

AllenJB

On , Sherif Ramadan wrote:
> Hmmm... I'm not really sure whether to consider this a language change 
> or
> not. I mean no syntax has changed, but sure it does break BC because of 
> the
> new notice. I'm really dubious about whether or not this demands an 
> RFC.
> I've seen more sweeping changes make it into a release with less 
> discussion
> and no RFC.
> 
> AllenJB, does this work the same for FAD and object properties? I 
> haven't
> tested your pull locally yet, but it looks good to me. If this covers 
> cases
> for both myFunc()['foo'] and $obj->prop['foo'] where neither is an 
> array
> then I think it's definitely worth getting into 7.0.0, but I'll have to
> checkout your pull later tonight and test it a bit more. It looks like
> based on the discussion you've pretty much covered all of my major 
> concerns
> with isset(), each(), and some of the other problems I saw from the PHP 
> 5
> attempts at fixing it.
> 
> Also, thanks for taking the time to put this together and fix all the 
> tests!
> 
> On Tue, Aug 25, 2015 at 12:02 PM, AllenJB <php.lists@allenjb.me.uk> 
> wrote:
> 
>> I have a pull request pending on this bug:
>> https://github.com/php/php-src/pull/1269
>> 
>> It's been discussed before ("Array dereferencing of scalars", 10th 
>> June
>> 2015 - I'm pretty sure it was discussed at least once more since then 
>> too)
>> and I was basically told it would require an RFC to get it accepted.
>> 
>> Unfortunately the RFC window had basically closed at that time (and 
>> work
>> got busy shortly after), so now I've been waiting until 7.0 is clear 
>> (as
>> well as me having the time to finish drafting the RFC).
>> 
>> AllenJB
>> 
>> 
>> 
>> On , Sherif Ramadan wrote:
>> 
>>> Hey Nicolai,
>>> 
>>> You're right. The notice is triggered by array_push behavior only, 
>>> which
>>> means that $x = true; echo $x['foo']; doesn't trigger the notice, 
>>> which is
>>> the same as your code above. Only write operations have historically
>>> resulted in this notice.
>>> 
>>> I would agree that providing the notice would help someone debugging
>>> potentially buggy code like this. Not sure if this is something we 
>>> can
>>> squeeze into 7.0.0 release at this point, but I would consider it a 
>>> bug
>>> fix
>>> with BC rather than something that should be subject to current 
>>> feature
>>> freeze.
>>> 
>>> 
>>> 
>>> On Tue, Aug 25, 2015 at 9:35 AM, Nicolai Scheer 
>>> <nicolai.scheer@gmail.com
>>> >
>>> wrote:
>>> 
>>> Hi all,
>>>> 
>>>> I'd expect the following code to throw a notice/warning:
>>>> 
>>>> $x = true;
>>>> $y = $x['foo'];
>>>> 
>>>> It executes completely silently.
>>>> $y is NULL afterwards, which is expected, since the right hand side 
>>>> of
>>>> the assignment is undefined.
>>>> 
>>>> If $x was an array (e.g. empty array), a E_NOTICE would be emitted.
>>>> 
>>>> Can anyone shed a light on this behaviour? If accessing non existing
>>>> array keys is worth a notice, shouldn't accessing an array index on 
>>>> a
>>>> non array be worth a notice as well (maybe even a warning)?
>>>> 
>>>> The other way round emits a warning (i.e. writing to an array key on 
>>>> a
>>>> non array):
>>>> 
>>>> $x = true;
>>>> $x['foo'] = 'bar';
>>>> 
>>>> Warning: Cannot use a scalar value as an array ...
>>>> 
>>>> Thanks for any insight,
>>>> 
>>>> greetings
>>>> 
>>>> Nico
>>>> 
>>> 
>> 
>>