Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56559
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4ECE0F47.1040504@lsces.co.uk>
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>
	<4ECD40E2.1000601@sugarcrm.com>
	<CAH-PCH6f30p6AfNT9z=wVPURo4ko08sMTwHiEQsdpauN-cYtwQ@mail.gmail.com>
	<4ECD48AD.1020207@sugarcrm.com>
	<4ECD91F4.5040303@gmail.com>
	<CAH-PCH7GCDOdnHve-mNdkPYbBN+WGLJN2BP8pdpXmVz=0FQ0mg@mail.gmail.com>
	<4ECDAEE5.7020205@gmail.com>
	<4ECE0887.3030109@lsces.co.uk>
	<4ECE0AC3.1050405@sugarcrm.com>
	<4ECE0F47.1040504@lsces.co.uk>
Date: Thu, 24 Nov 2011 10:53:23 +0100
Message-ID: <CAH-PCH57T-VoAnG8+iYxT6fbjMRqc9CaUCN3EbLfz0c+cmdrHg@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=0016363b8ec2e3763904b27801d0
Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
From: tyra3l@gmail.com (Ferenc Kovacs)

--0016363b8ec2e3763904b27801d0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Nov 24, 2011 at 10:32 AM, Lester Caine <lester@lsces.co.uk> wrote:

> Stas Malyshev wrote:
>
>> Hi!
>>
>>  That would help a lot ... this is not a problem of "so the developer ca=
n
>>> fix his
>>> code" but rather so we can fix legacy code which other non-developers a=
re
>>> currently using happily ... If *I* had written the code I would not hav=
e
>>> done it
>>> the way it is currently structured, but I'm not about to spend time
>>> re-engineering it ... I just want to plug the holes quickly so it
>>> continues to
>>> work.
>>>
>>
>> OK, notice is probably technically feasible, though I still not like the
>> idea
>> too much. When you want to produce this notice? Producing it on any
>> string would
>> probably break code like $a['1'] which has it's legitimate uses and I'm
>> sure can
>> be seen around. Should be produce notice if the string has non-numeric
>> chars?
>> That's slow down this operation a little, though probably not critically
>> as
>> conversion is going to scan the string anyway.
>>
>
> The 'index not found' error usually pops up where I'm messing up the
> existing 'logic' so something that flags that a 'phantom' index has been
> created when a 'real' ['sub-element'] was being looked for. In my own cas=
e
> I'm sure once I dig out the problem the answer will be obvious as well, b=
ut
> I simply don't have the time to spend. So currently a production 5.4
> upgrade is not possible.
>
> It would be useful if some of the other people flagging this problem coul=
d
> provide some info on what is failing ... the original PEAR problem for
> example? I'm not sure that any of us know just what edge case is causing =
a
> hickup?
>
>
Without debugging the exact problem or having a script replicating the
different behavior between 5.3. and 5.4, your feedback doesn't really
provide anything valuable, as it can be caused by this change, or something
else.
We only aware of two behavior difference between 5.3 and 5.4 related to
this particular change:
- offset chaining works now, while it was throwing a fatal error in 5.3
($string[0][0][0] returns the first character of $string)
- which means that the type juggling behavior (unrelated to this change,
also exists in 5.3) can occur not just for $string['foo'] but for
$array['string_exists_where_array_expected']['foo'] also (this is what
Daniel bumped into in the PEAR tests).

--=20
Ferenc Kov=C3=A1cs
@Tyr43l - http://tyrael.hu

--0016363b8ec2e3763904b27801d0--