Re: 5.4 regression: non-existent sub-sub keys now have values

On Wed, Nov 23, 2011 at 3:42 PM, Gustavo Lopes <glopes@nebm.ist.utl.pt>wrote: > 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 = array('exists' => 'foo'); >>> echo $b['blah'] . "\n"; >>> >>> $a = '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 = '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'] = null; > var_dump($a); > ^D > array(1) { > ["2 cats"]=> > 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 what > 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 lax > rules are followed: > > <?php > $a = '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<http://hu.php.net/manual/en/language.types.string.php#language.types.string.substr> "Non-integer types are converted to integer." So it is a documented behavior, so the current change is just a bugfix imo. -- Ferenc Kovács @Tyr43l - http://tyrael.hu