# 5.4 regression: non-existent sub-sub keys now have values - Thread: https://externals.io/message/56477 - Original archive: https://news-web.php.net/php.internals/56477 - Started by Daniel Convissor on 2011-11-23T01:50:08+00:00 - Messages: 88 - Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/56477.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #56477 — Daniel Convissor — 2011-11-23T01:50:08+00:00 URL: https://externals.io/message/56477#56477 Hi Folks: I just stumbled upon a regression in 5.4. In an array, a sub-sub-key of an existing key is now returning a letter of the value indexed by the main key. I'm raising it here so it doesn't get lost. https://bugs.php.net/bug.php?id=60362 Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #56478 — Etienne Kneuss — 2011-11-23T02:26:07+00:00 URL: https://externals.io/message/56477#56478 · In reply to: #56477 Hi, AFAIK this is one of the change that was explicitly put in to make it more consistent. Before, you had: $string = "asd"; $string[0] == "a" but: $string[0][0] == Fatal: cannot use string offset as an array while $string[0] == "a", it makes no sense for $string[0][0] not to return "a" again, since $str = "a"; $str[0] == "a"; Best Regards, On Wed, Nov 23, 2011 at 02:50, Daniel Convissor wrote: > Hi Folks: > > I just stumbled upon a regression in 5.4.  In an array, a sub-sub-key of > an existing key is now returning a letter of the value indexed by the > main key.  I'm raising it here so it doesn't get lost. > > https://bugs.php.net/bug.php?id=60362 > > Thanks, > > --Dan > > -- >  T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y >            data intensive web and database programming >                http://www.AnalysisAndSolutions.com/ >  4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409 > > -- > > > > -- Etienne Kneuss http://www.colder.ch --- ## #56479 — Daniel Convissor — 2011-11-23T02:31:08+00:00 URL: https://externals.io/message/56477#56479 · In reply to: #56478 Hi Etienne: > AFAIK this is one of the change that was explicitly put in to make it > more consistent. But now it breaks code in the wild. I came across this due to an isset() in PEAR now passing when it didn't before. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #56480 — Etienne Kneuss — 2011-11-23T02:36:34+00:00 URL: https://externals.io/message/56477#56480 · In reply to: #56479 On Wed, Nov 23, 2011 at 03:31, Daniel Convissor wrote: > Hi Etienne: > > > […] > > But now it breaks code in the wild.  I came across this due to an > isset() in PEAR now passing when it didn't before. PEAR is definitely doing some strange things :) Is it checking indices of a variables without checking first if it's an array? Sounds like the comeback of "Please don't break bad code!" seen with is_a :) IMO it still makes sense to make that change for 5_4, makes everything less magic and more consistent. > > Thanks, > > --Dan > > -- >  T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y >            data intensive web and database programming >                http://www.AnalysisAndSolutions.com/ >  4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409 > -- Etienne Kneuss http://www.colder.ch --- ## #56481 — Stas Malyshev — 2011-11-23T05:22:54+00:00 URL: https://externals.io/message/56477#56481 · In reply to: #56480 Hi! > PEAR is definitely doing some strange things :) Is it checking indices > of a variables without checking first if it's an array? > Sounds like the comeback of "Please don't break bad code!" seen with is_a :) I think somebody should start a code cleanup effort :) We can't build all PHP development around preserving every line of bad code doing bad things around. We care about BC but there should be some limits, and bug compatibility is beyond those limits. We long had array access syntax on strings. Expression $a[0]["foo"] where $a[0] is a string has long been treated as $a[0][0] and returned first letter of $a[0] (btw code doing this is already a bug, even though PHP lets you get away with it - but I'd put some notice there). Since this letter is a string, it should behave the same as other strings. Otherwise this code: echo $a[0]["foo"]["bar"] and this one: $b = $a[0]["foo"]; echo $b["bar"]; behave differently, which was a huge WTF and can only be considered a bug. Any code relying on this should be considered a bug too and fixed immediately. I can not think of any legitimate reason for the code to rely on such things. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #56484 — Lester Caine — 2011-11-23T08:56:41+00:00 URL: https://externals.io/message/56477#56484 · In reply to: #56480 Etienne Kneuss wrote: > > […] > PEAR is definitely doing some strange things:) Is it checking indices > of a variables without checking first if it's an array? > Sounds like the comeback of "Please don't break bad code!" seen with is_a:) > > IMO it still makes sense to make that change for 5_4, makes everything > less magic and more consistent. I'm having a lot of trouble with working out WHAT is going on here at all. https://bugs.php.net/bug.php?id=60362 as far as I can tell is using array and sub array elements? Strings don't come into the equation? So I check if I've populated the sub-array be seeing if a sub array element exists, such as would happen if I've populated the array in a previous scan through, but now I'm getting sub array elements caused by some conversion of the string making up the element above? Now that this activity has been highlighted it may well explain why I'm getting problems with a section of code that is building a complex tree structure array from GEDCOM data strings ... since the code is not my own working out where things were breaking down was a problem I simply do not have time to investigate. It currently fails on PHP5.4 and it took some time to tidy the code on 5.3 ... and that still only runs with warnings switched off :( So what is the current preferred method of checking if sub array elements have been created manually, rather than as 'less magic' string elements? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #56486 — Laruence — 2011-11-23T09:06:09+00:00 URL: https://externals.io/message/56477#56486 · In reply to: #56484 Hi: I think it is really need make some difference between {} and [] :) thanks > Etienne Kneuss wrote: > > […] > > I'm having a lot of trouble with working out WHAT is going on here at all. > > https://bugs.php.net/bug.php?id=60362 as far as I can tell is using array > and sub array elements? Strings don't come into the equation? So I check if > I've populated the sub-array be seeing if a sub array element exists, such > as would happen if I've populated the array in a previous scan through, but > now I'm getting sub array elements caused by some conversion of the string > making up the element above? > > Now that this activity has been highlighted it may well explain why I'm > getting problems with a section of code that is building a complex tree > structure array from GEDCOM data strings ... since the code is not my own > working out where things were breaking down was a problem I simply do not > have time to investigate. It currently fails on PHP5.4 and it took some time > to tidy the code on 5.3 ... and that still only runs with warnings switched > off :( > > So what is the current preferred method of checking if sub array elements > have been created manually, rather than as 'less magic' string elements? > > -- > Lester Caine - G8HFL > ----------------------------- > Contact - http://lsces.co.uk/wiki/?page=contact > L.S.Caine Electronic Services - http://lsces.co.uk > EnquirySolve - http://enquirysolve.com/ > Model Engineers Digital Workshop - http://medw.co.uk// > Firebird - http://www.firebirdsql.org/index.php > > -- > > > > -- Laruence  Xinchen Hui http://www.laruence.com/ --- ## #56487 — Ferenc Kovacs — 2011-11-23T09:24:35+00:00 URL: https://externals.io/message/56477#56487 · In reply to: #56484 > Etienne Kneuss wrote: > > > […] > > I'm having a lot of trouble with working out WHAT is going on here at all. > > https://bugs.php.net/bug.php?**id=60362as far as I can tell is using array and sub array elements? Strings don't > come into the equation? So I check if I've populated the sub-array be > seeing if a sub array element exists, such as would happen if I've > populated the array in a previous scan through, but now I'm getting sub > array elements caused by some conversion of the string making up the > element above? > > Now that this activity has been highlighted it may well explain why I'm > getting problems with a section of code that is building a complex tree > structure array from GEDCOM data strings ... since the code is not my own > working out where things were breaking down was a problem I simply do not > have time to investigate. It currently fails on PHP5.4 and it took some > time to tidy the code on 5.3 ... and that still only runs with warnings > switched off :( > > So what is the current preferred method of checking if sub array elements > have been created manually, rather than as 'less magic' string elements? > > some clarification: in the test script, Daniel declared $arr as: $arr = array('exists' => 'foo'); so when he tests $arr['exists']['non_existent'] PHP will see that $arr['exists'] is a string, and it will convert the 'non_existent' index to int(0) and that will return the same as $arr['exists'][0]: 'f' If he would have defined $arr['exists'] as an array, then the code would work as he expected, empty would returned true for $arr['exists']['non_existent'] -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56489 — Stas Malyshev — 2011-11-23T09:26:46+00:00 URL: https://externals.io/message/56477#56489 · In reply to: #56484 Hi! > > I'm having a lot of trouble with working out WHAT is going on here at all. 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". Now what happens if you do $a[0][0]? Since $a[0] is "f", $a[0][0] should be first letter of "f" which is "f" again, right? Only in 5.3 it did not work because of some deficiencies in implementation of string offsets. In 5.4 it was fixed. Now the situation in the bug - what happens if we do $a['blah']['foobar']? As we noted before, it's the same as $a[0][0] and thus produces "f" in 5.4. In 5.3 it didn't work because of the above deficiency. That's it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #56494 — Lester Caine — 2011-11-23T09:51:35+00:00 URL: https://externals.io/message/56477#56494 · In reply to: #56487 Ferenc Kovacs wrote: > some clarification: > in the test script, Daniel declared $arr as: > $arr = array('exists' => 'foo'); > so when he tests > $arr['exists']['non_existent'] > PHP will see that $arr['exists'] is a string, and it will convert the > 'non_existent' index to int(0) and that will return the same > as $arr['exists'][0]: 'f' > If he would have defined $arr['exists'] as an array, then the code would work as > he expected, empty would returned true for $arr['exists']['non_existent'] The bit I am missing here is the statement that $arr = array ... has NOT created an array with an element ['exists'] ... I suspect that this is perhaps where the code *I* am looking at is breaking down ... how SHOULD you define the array so that it is an array? So that $family = array ( 'fam1' => 'JONES' ); is the base for the JONES family rather than simply a string. All of this USED to be simple, but it seems to be getting so cryptic that this is what is causing the trouble :( -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #56495 — Ferenc Kovacs — 2011-11-23T09:58:29+00:00 URL: https://externals.io/message/56477#56495 · In reply to: #56494 > Ferenc Kovacs wrote: > > > […] > > The bit I am missing here is the statement that $arr = array ... has NOT > created an array with an element ['exists'] yes it did, but ['exists'] wasn't defined as an array, but as a string. > ... I suspect that this is perhaps where the code *I* am looking at is > breaking down ... how SHOULD you define the array so that it is an array? > So that $family = array ( 'fam1' => 'JONES' ); is the base for the JONES > family rather than simply a string. All of this USED to be simple, but it > seems to be getting so cryptic that this is what is causing the trouble :( I think you just need a coffee. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56498 — Lester Caine — 2011-11-23T10:51:12+00:00 URL: https://externals.io/message/56477#56498 · In reply to: #56495 Ferenc Kovacs wrote: > > > On Wed, Nov 23, 2011 at 10:51 AM, Lester Caine > wrote: > > Ferenc Kovacs wrote: > > some clarification: > in the test script, Daniel declared $arr as: > $arr = array('exists' => 'foo'); > so when he tests > $arr['exists']['non_existent'] > PHP will see that $arr['exists'] is a string, and it will convert the > 'non_existent' index to int(0) and that will return the same > as $arr['exists'][0]: 'f' > If he would have defined $arr['exists'] as an array, then the code would > work as > he expected, empty would returned true for $arr['exists']['non_existent'] > > > The bit I am missing here is the statement that $arr = array ... has NOT > created an array with an element ['exists'] > > yes it did, but ['exists'] wasn't defined as an array, but as a string. THAT was what was confusing things ... but I wonder what code was failing in PEAR? The code here was looking for an array element to check that the ARRAY had been populated, but the holding element was just a simple string rather than an empty array. > ... I suspect that this is perhaps where the code *I* am looking at is > breaking down ... how SHOULD you define the array so that it is an array? So > that $family = array ( 'fam1' => 'JONES' ); is the base for the JONES family > rather than simply a string. All of this USED to be simple, but it seems to > be getting so cryptic that this is what is causing the trouble :( The legacy code methods may be wrong, but a lot of this code originates in PHP4 days, so when things do break what is needed is a clean upgrade guide which may help to isolate the bugs when they appear? > I think you just need a coffee. No just a version of PHP where I'm not firefighting changes but getting back to actually producing new code :( I can either test 5.4 or work ... I don't have time for both ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #56504 — Daniel Convissor — 2011-11-23T14:14:09+00:00 URL: https://externals.io/message/56477#56504 · In reply to: #56489 Hi Stas: > 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. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #56505 — Ferenc Kovacs — 2011-11-23T14:19:42+00:00 URL: https://externals.io/message/56477#56505 · In reply to: #56504 On Wed, Nov 23, 2011 at 3:14 PM, Daniel Convissor < danielc@analysisandsolutions.com> wrote: > Hi Stas: > > > […] > > 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 if we allow strings to be used as indexes for strings, we have to be consistent with what we have already. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56506 — Gustavo Lopes — 2011-11-23T14:42:41+00:00 URL: https://externals.io/message/56477#56506 · In reply to: #56505 Em Wed, 23 Nov 2011 14:19:42 -0000, Ferenc Kovacs escreveu: > On Wed, Nov 23, 2011 at 3:14 PM, Daniel Convissor < > danielc@analysisandsolutions.com> wrote: > > > […] > > > 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 > But this is *not* (and afaik has never been) how indexes in arrays work. The conversion of array keys has always different rules: `NULL` } 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: if we allow strings to be used as indexes for strings, we have to be > consistent with what we have already. Short notice to avoid confusion: It has nothing to do with allowing string, or double, or whatever else but loosely typing. Loosely typing is what is happening here, the op fetching a byte gets an integer, as usual. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #56508 — Ferenc Kovacs — 2011-11-23T14:54:43+00:00 URL: https://externals.io/message/56477#56508 · In reply to: #56506 On Wed, Nov 23, 2011 at 3:42 PM, Gustavo Lopes wrote: > Em Wed, 23 Nov 2011 14:19:42 -0000, Ferenc Kovacs > escreveu: > > On Wed, Nov 23, 2011 at 3:14 PM, Daniel Convissor < > > […] > But this is *not* (and afaik has never been) how indexes in arrays work. > The conversion of array keys has always different rules: > > $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: > > $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 "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 --- ## #56510 — Daniel Convissor — 2011-11-23T15:04:09+00:00 URL: https://externals.io/message/56477#56510 · In reply to: #56508 Hi Ferenc: [And the manual saaaays...] > "Non-integer types are converted to integer." > So it is a documented behavior, so the current change is just a bugfix imo. Can someone please lend me their time machine so I can go back and tell folks to just use {} for string offsets and [] for arrays? I'll only need it for a few minutes. Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #56511 — Ferenc Kovacs — 2011-11-23T15:21:07+00:00 URL: https://externals.io/message/56477#56511 · In reply to: #56510 On Wed, Nov 23, 2011 at 4:04 PM, Daniel Convissor < danielc@analysisandsolutions.com> wrote: > Hi Ferenc: > > [And the manual saaaays...] > > […] > imo. > > Can someone please lend me their time machine so I can go back and tell > folks to just use {} for string offsets and [] for arrays? I'll > only need it for a few minutes. offtopic: I used to preach about using {} for string offsets and that [] is deprecated then we had that reversed in the documentation/5.3 migration guide ("The use of {} to access string offsets is deprecated. Use [] instead.")... Fortunately it turned out to be a mistake, and got fixed in the docs, since then we document both behavior (albeit the [] seems to be preferred way in the docs), and none of them triggers E_DEPRECATED. So I think that it is the reason why people still use [] for string offsets. -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56515 — Daniel Convissor — 2011-11-23T15:31:00+00:00 URL: https://externals.io/message/56477#56515 · In reply to: #56504 Hi Again Folks: > $a = 'foo'; > echo $a['blah'] . "\n"; > > But that second one echos out "f". This is a huge WTF. Two things for the record on this front. First, i've been actively using PHP for, what, ten years or so, and have never run into this behavior before. Second, this behavior turns the following one liner: if (isset($arr['package']['attribs']['version'])) { Into this: if (is_array($arr) && array_key_exists('package', $arr) && is_array($arr['package']) && array_key_exists('attribs', $arr['package']) && is_array($arr['package']['attribs']) && array_key_exists('version', $arr['package']['attribs']) && !empty($arr['package']['attribs']['version'])) { Thanks, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409 --- ## #56516 — Ferenc Kovacs — 2011-11-23T15:40:25+00:00 URL: https://externals.io/message/56477#56516 · In reply to: #56515 On Wed, Nov 23, 2011 at 4:31 PM, Daniel Convissor < danielc@analysisandsolutions.com> wrote: > Hi Again Folks: > > > > […] > > Two things for the record on this front. First, i've been actively > using PHP for, what, ten years or so, and have never run into this > behavior before. Second, this behavior turns the following one liner: > > if (isset($arr['package']['attribs']['version'])) { > > Into this: > > if (is_array($arr) > && array_key_exists('package', $arr) > && is_array($arr['package']) > && array_key_exists('attribs', $arr['package']) > && is_array($arr['package']['attribs']) > && array_key_exists('version', $arr['package']['attribs']) > && !empty($arr['package']['attribs']['version'])) > { > it is only necessary if you can't guarantee your data structure (so that you can get a string where you expect an array) -- Ferenc Kovács @Tyr43l - http://tyrael.hu --- ## #56517 — Richard Quadling — 2011-11-23T17:58:42+00:00 URL: https://externals.io/message/56477#56517 · In reply to: #56515 On 23 November 2011 15:31, Daniel Convissor wrote: > Hi Again Folks: > > > > […] > > Two things for the record on this front.  First, i've been actively > using PHP for, what, ten years or so, and have never run into this > behavior before.  Second, this behavior turns the following one liner: > >        if (isset($arr['package']['attribs']['version'])) { > > Into this: > >        if (is_array($arr) >                && array_key_exists('package', $arr) >                && is_array($arr['package']) >                && array_key_exists('attribs', $arr['package']) >                && is_array($arr['package']['attribs']) >                && array_key_exists('version', $arr['package']['attribs']) >                && !empty($arr['package']['attribs']['version'])) >        { I agree with Daniel on this. Just looking for any test relating to isset() to see what tests will now fail. Neither of the isset() tests ext/standard/tests/general_functions look at arrays with associative indices. The behaviour with regard to unavailable associative indices has no tests. But using loose typing as a fallback for non existent keys seems really really wrong. Especially if the key is a constant. On what planet should ... isset($arr['exists']['test_existance']) should become isset($arr['exists'][0]) That just seems really wrong and the work around is awful. -- Richard Quadling Twitter : EE : Zend : PHPDoc : Fantasy Shopper @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea : fan.sh/6/370 --- ## #56518 — Lester Caine — 2011-11-23T18:13:45+00:00 URL: https://externals.io/message/56477#56518 · In reply to: #56517 Richard Quadling wrote: > I agree with Daniel on this. > > Just looking for any test relating to isset() to see what tests will now fail. So it's not just me :) I am seeing this break real world projects and can't see a easy way to fix the break. There is nothing really wrong with the current code except that the sub keys have yet to be populated. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php --- ## #56519 — Pierre Joye — 2011-11-23T18:22:50+00:00 URL: https://externals.io/message/56477#56519 · In reply to: #56517 > Just looking for any test relating to isset() to see what tests will now fail. > > Neither of the isset() tests ext/standard/tests/general_functions look > at arrays with associative indices. > > The behaviour with regard to unavailable associative indices has no tests. > > But using loose typing as a fallback for non existent keys seems > really really wrong. > > Especially if the key is a constant. On what planet should ... > > isset($arr['exists']['test_existance']) should become isset($arr['exists'][0]) > > That just seems really wrong and the work around is awful. That's exactly why I stoped to use this syntax a long time ago. And I was in favor to deprecate it and actually remove it the next major release (6 that is). But that's another discussion. Unless I'm mistaken it seems that we have a clear and vicious BC break here, the kind of changes that are annoying to catch and does not bring a lot of benefits to PHP (given the actual usage of this syntax). I would go with a revert, add tests and never change this behavior again. It is a confusing enough topic. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #56521 — Etienne Kneuss — 2011-11-23T18:34:40+00:00 URL: https://externals.io/message/56477#56521 · In reply to: #56519 Hi, What people seem to have trouble with here is not that $string[0][0] == $string[0], but rather that $string['index'] === $string[0]... But as many people said, it is just how type juggling want: string index? Get me an int => 0. I believe the change introduced in 5.4 makes sense, the previous way it worked made no sense and was simply an anomaly. It is clear from this thread that the confusion comes from strings as string offsets, something "totally" different, but changing that would be a much bigger BC break I guess. Best, > > > > […] > > That's exactly why I stoped to use this syntax a long time ago. And I > was in favor to deprecate it and actually remove it the next major > release (6 that is). But that's another discussion. > > Unless I'm mistaken it seems that we have a clear and vicious BC break > here, the kind of changes that are annoying to catch and does not > bring a lot of benefits to PHP (given the actual usage of this > syntax). I would go with a revert, add tests and never change this > behavior again. It is a confusing enough topic. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > > > > -- Etienne Kneuss http://www.colder.ch --- Next page: https://externals.io/message/56477.md?page=2