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

On Thu, Nov 24, 2011 at 10:48 PM, Rasmus Lerdorf <rasmus@lerdorf.com> wrote: > On 11/24/2011 01:44 PM, Yasuo Ohgaki wrote: > > Hi all, > > > > I should think twice before seding mail. "abc" as array index is > > converted to 0 since it's not a integer. So with current code is > > behave consistently with regards to string to long conversion. > > > > However, > > > > PHP 5.3 > > php -r '$s = "abc"; var_dump($s[0]["bar"]);' > > PHP Fatal error: Cannot use string offset as an array in Command line > > code on line 1 > > > > PHP 5.4 > > ./php -r '$s = "abc"; var_dump($s[0]["bar"]);' > > string(1) "a" > > > > Isn't it better to raise notice for accessing string by string index? > > There is no use to allowing string index access to strings. I think > > raising notice is feasible. Isn't it? > > String index access is still required since they are often numeric > strings. We could add a notice for non-numeric strings, but the check > would slow things down a bit. yeah, as I mentioned before: "The other improvement (related but not introduced in this change) that I suggested was that we could also trigger a notice when a "non-applicable" string offset is passed(defining non-applicable is a little bit hard, because of the current type-juggling rules, we have to allow $string["1"], because '1" can come from a database, or get/post, where it would be a string, not an int, but if we go with the current type juggling, $string["2_foo_3"] would also be converted to $string[2], which isn't really intended imo. ." I would vote for allowing only numbers in the string index/offset: [0-9]+ -- Ferenc Kovács @Tyr43l - http://tyrael.hu