Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56525
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ECD40E2.1000601@sugarcrm.com>
References: <20111123015008.GA12933@panix.com>
	<CACQesk6UuGUgyJz3hsGVE0crJx3GCkjTTpLb4xNGTm1goLzO8Q@mail.gmail.com>
	<20111123023108.GA172@panix.com>
	<CACQesk5kj=4kzvTDiLL1oOLBXZrn4WdUcLXdbyMLTa=OdhGTcw@mail.gmail.com>
	<4ECCB549.904@lsces.co.uk>
	<4ECCBC56.3050602@sugarcrm.com>
	<20111123141408.GA11940@panix.com>
	<4ECD40E2.1000601@sugarcrm.com>
Date: Wed, 23 Nov 2011 20:10:43 +0100
Message-ID: <CAH-PCH6f30p6AfNT9z=wVPURo4ko08sMTwHiEQsdpauN-cYtwQ@mail.gmail.com>
To: Stas Malyshev <smalyshev@sugarcrm.com>
Cc: Daniel Convissor <danielc@analysisandsolutions.com>, Lester Caine <lester@lsces.co.uk>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=20cf3074b93c36c42204b26bad52
Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf3074b93c36c42204b26bad52
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2011 at 7:52 PM, Stas Malyshev <smalyshev@sugarcrm.com>wrot=
e:

> Hi!
>
>
> On 11/23/11 6:14 AM, Daniel Convissor wrote:
>
>> To me, this is the bug.  $a['blah'] does not exist.  An undefined index
>>
>
> If it's a bug, this bug was in PHP since forever, nothing new here.
>
>
>  notice should be raised.  The key "blah" should not be converted to 0.
>> The following two things should behave the same:
>>
>> $b =3D array('exists' =3D>  'foo');
>> echo $b['blah'] . "\n";
>>
>> $a =3D 'foo';
>> echo $a['blah'] . "\n";
>>
>
> No they should not. First is array access, second is string offset access=
,
> totally different ops. That's like saying + on arrays should calculate th=
e
> sum of all array elements because + on numbers calculates the sum.
> Operators have different meanings for different types, it has always been
> so in all languages.
> One could argue that string access with non-string should produce a
> notice, but probably if we added that a lot of people would come out to
> complain we broke their perfectly working code ;)


I think that it would make sense.
I mean using $foo['asd'] where $foo is a string is as likely to be a hidden
application bug as the array() =3D> 'Array' conversion that we patched
recently to trigger a warning.

More clarification for the others who seems to be miss how specific this
change is:
The only case where the 5.4 branch works differently as before if you
reference a string type(int, float, etc. won't trigger this) variable using
an associative index and you expect it that to be undefined variable even
though that the documentation explicitly states that the index will be
converted to an integer in this case.
for example:

$foo =3D 'string';
echo isset($foo['bar']);

will return true (as $foo['bar'] will converted to $foo[0] which returns
's' in this case) in 5.4 while it returned false previously.

ps:
on a sidenote: the same change also introduces that using the following:
$foo[0][0][0]... on a non-empty string will be always valid, before this
change it produced a "PHP Fatal error:  Cannot use string offset as an
array"

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf3074b93c36c42204b26bad52--