It might have been better to have waited for the is_a() fix to get
sorted out.. - It's a very annoying BC break (changes the documented
behaviour), and now it means we need 4.3.9 in a few more days.
Let me know if you need help testing / applying etc..
Regards
Alan
On Wednesday, August 24, 20
ut breaking any code.
Regards
Alan
On Wednesday, August 24, 2011 03:44 PM, Ferenc Kovacs wrote:
On Wed, Aug 24, 2011 at 3:57 AM, a...@akbkhome.com wrote:
It might have been better to have waited for the is_a() fix to get sorted
out.. - It's a very annoying BC break (changes the document
ase it's not clear, a
situation where is_a("bar", "foo") returns FALSE, even though bar extends foo,
but bar simply doesn't happen to be loaded in memory at the time of the call - can lead to very
real world bugs.
Zeev
-Original Message-
From: a...
" If it's a clear bug, which IMHO this is_a() issue was - then unless
we're looking at code breakage at massive scale, it should be fixed. "
mmh.. how much breakage did you want.
PEAR::isError is basically is_a($input, 'PEAR_Error'); it's been like
that for > 8 years
google search for PE
I'm not sure it's possible to get agreement on if this is a bug or not,
you might see a bug, I just see this as a pointless change for
consistency that pretty much nobody will ever need or use.
I think I'll leave it as
a) no bug was ever reported on the previous behaviour.
b) intended "design"
It did not like my search for is_a ;) - I guess it's too short.
On Thursday, August 25, 2011 11:59 AM, Ronald Chmara wrote:
On Wed, Aug 24, 2011 at 6:51 PM, a...@akbkhome.com wrote:
BTW. we could really do with a searchable archive of php.dev + internals...
- It's pretty difficult t
