Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56607
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain akbkhome.com designates 202.81.246.113 as permitted sender)
Message-ID: <4ECEFE1F.4070504@akbkhome.com>
Date: Fri, 25 Nov 2011 10:31:59 +0800
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Icedove/3.1.13
MIME-Version: 1.0
To: devis@lucato.it
CC: Rasmus Lerdorf <rasmus@lerdorf.com>, 
 Yasuo Ohgaki <yohgaki@ohgaki.net>,
 RQuadling@gmail.com, Daniel Convissor <danielc@analysisandsolutions.com>, 
 PHP Internals List <internals@lists.php.net>
References: <20111123015008.GA12933@panix.com> <CAKUjMCWpv98-+VfxkSEjCgRDXJ5KXZaGCEA=0Q=h0kvXEtuGHg@mail.gmail.com> <CAGa2bXYARXzPXA5FS8q2ycmpULx9Y2BTVgdkcQireso1iUVN9Q@mail.gmail.com> <CAGa2bXa6xxz8P9XRvtag61A76Lrk99iQM2wrRa+QD+BkQukgLQ@mail.gmail.com> <4ECEBBB8.90604@lerdorf.com> <CAET_qdMBDG2pL_h=NBeWJxABO-4G5sBNLcM6=t0rAh0-zQeQgA@mail.gmail.com>
In-Reply-To: <CAET_qdMBDG2pL_h=NBeWJxABO-4G5sBNLcM6=t0rAh0-zQeQgA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have
 values
From: alan@akbkhome.com (Alan Knowles)

On Friday, November 25, 2011 08:23 AM, devis@lucato.it wrote:
> On 24 November 2011 21:48, 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.
>>
>> -Rasmus
>>
>
> Would it be possible to have that check only if E_NOTICE is enabled ?
> That would allow to limit the cost to development environments
> (assuming one could disable E_NOTICEs on production env).
>
> Devis
This is a design issue of using the same syntax for arrays and strings, 
and accepting string indexes for both, I think this is beginning to 
illustrate some of the flaws in that design.

if (isset($_POST['query']['search'])) { << This does not do what you 
think (if ?query=a_string..

Although the chained string offset fix is probably the right thing to 
do, I think it should be reverted in this version, then this process occur:

5.4
- revert chained string offsets
- add E_NOTICE to any usage of string index's of string  eg . $a = 
"string" ; $a["string"] = gives E_NOTICE
- users can add (int) if they really need to check string indexes of a 
string
- isset($string['x']) will return true as present
- isset($string['x']['x']) will return false as present

5.5
  - reapply chained string offsets
  - add E_FATAL to any usage of string index's of string = eg . $a = 
"string" ; $a["string"] = gives E_FATAL ????
  - make $a["string"] return an empty string - so isset() on chained 
string offsets will work as expected.
  - isset($string['x']) will return false as per the warning on the 
previous version..
  - isset($string['x']['x']) will return false as present

Thoughts.........

Regards
Alan