Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56508
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: <op.v5eltf1tidpuyk@clk-0081.mshome.net>
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>
	<CAH-PCH7hSXLsyctYML-TSGyk4a1tZsHZrFn5SyeKv-6uLDYD7g@mail.gmail.com>
	<op.v5eltf1tidpuyk@clk-0081.mshome.net>
Date: Wed, 23 Nov 2011 15:54:43 +0100
Message-ID: <CAH-PCH4-QmtDp=eO4Fo3_sHWmVizMdzon-VpX3sWS8pr=7ovNw@mail.gmail.com>
To: Gustavo Lopes <glopes@nebm.ist.utl.pt>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary=20cf303346bfb0354204b2681968
Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
From: tyra3l@gmail.com (Ferenc Kovacs)

--20cf303346bfb0354204b2681968
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Nov 23, 2011 at 3:42 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrot=
e:

> Em Wed, 23 Nov 2011 14:19:42 -0000, Ferenc Kovacs <tyra3l@gmail.com>
> escreveu:
>
>  On Wed, Nov 23, 2011 at 3:14 PM, Daniel Convissor <
>> danielc@analysisandsolutions.**com <danielc@analysisandsolutions.com>>
>> wrote:
>>
>>  > It's actually very simple. Take variable $a which is a string
>>> > ("foo"). Now it you do $a[0] that would produce first letter - "f".
>>> > Now here's a tricky part - if you do $a['blah'] it would convert
>>> > 'blah' to number, get 0 and return the same letter "f".
>>>
>>> To me, this is the bug.  $a['blah'] does not exist.  An undefined index
>>> 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";
>>>
>>> But that second one echos out "f".  This is a huge WTF.
>>>
>>
>>
>> and the following should also behave the same:
>> $a =3D 'foo';
>>
>> echo $a[2];
>> echo $a['2'];
>> echo $a['2 cats'];
>>
>> because this is how the type juggling works in php:
>> http://php.net/manual/en/**language.types.type-juggling.**php<http://php=
.net/manual/en/language.types.type-juggling.php>
>>
>>
> But this is *not* (and afaik has never been) how indexes in arrays work.
> The conversion of array keys has always different rules:
>
> <?php
> $a['2 cats'] =3D null;
> var_dump($a);
> ^D
> array(1) {
>  ["2 cats"]=3D>
>  NULL
> }
>

yeah, because using associative arrays (hence strings as indexes) is a sane
operation.
but we are talking about strings here.


>
> The mapping between strings and integers used for arrays is 1 to 1, and
> strings that can be mapped to integers are always mapped (so you cannot
> have a '1' (string) key and a 1 (int) key). These different rules are wha=
t
> makes possible to store any kind of string in an array, and changing this
> would be a huge error.
>
> I see, however, that it's not the case for indexing strings, where the la=
x
> rules are followed:
>
> <?php
> $a =3D 'foo';
> var_dump($a['2 cats']);
> ^D
> string(1) "o"
>
> If there's any change to be made, it would be to change the way string
> indexing works, not the other way around.
>
>
php.net/manual/en/language.types.string.php#language.types.string.substr<ht=
tp://hu.php.net/manual/en/language.types.string.php#language.types.string.s=
ubstr>
"Non-integer types are converted to integer."
So it is a documented behavior, so the current change is just a bugfix imo.

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--20cf303346bfb0354204b2681968--