Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56486
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.170 as permitted sender)
MIME-Version: 1.0
Sender: laruence@gmail.com
In-Reply-To: <4ECCB549.904@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>
Date: Wed, 23 Nov 2011 17:06:09 +0800
Message-ID: <CABBJUpc_szzJYAVEa5y-LnorraGnj7yb1nAXhN7jAXY6=NKgOw@mail.gmail.com>
To: Lester Caine <lester@lsces.co.uk>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values
From: laruence@php.net (Laruence)

Hi:

I think it is really need make some difference between {} and []

:)

thanks

On Wed, Nov 23, 2011 at 4:56 PM, Lester Caine <lester@lsces.co.uk> wrote:
> Etienne Kneuss wrote:
>>>>
>>>> AFAIK this is one of the change that was explicitly put in to make it
>>>> >> =C2=A0more consistent.
>>>
>>> >
>>> > =C2=A0But now it breaks code in the wild. =C2=A0I came across this du=
e to an
>>> > =C2=A0isset() in PEAR now passing when it didn't before.
>>
>> PEAR is definitely doing some strange things:) =C2=A0Is it checking indi=
ces
>> 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=3D60362 as far as I can tell is using arr=
ay
> 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, suc=
h
> as would happen if I've populated the array in a previous scan through, b=
ut
> now I'm getting sub array elements caused by some conversion of the strin=
g
> 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 t=
ime
> to tidy the code on 5.3 ... and that still only runs with warnings switch=
ed
> 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=3Dcontact
> 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
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>



--=20
Laruence =C2=A0Xinchen Hui
http://www.laruence.com/