Etienne Kneuss wrote:
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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
