Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54853 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 70439 invoked from network); 24 Aug 2011 09:37:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Aug 2011 09:37:37 -0000 Authentication-Results: pb1.pair.com header.from=alan@akbkhome.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=alan@akbkhome.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain akbkhome.com designates 202.81.246.113 as permitted sender) X-PHP-List-Original-Sender: alan@akbkhome.com X-Host-Fingerprint: 202.81.246.113 246-113.netfront.net Received: from [202.81.246.113] ([202.81.246.113:60062] helo=246-113.netfront.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 78/14-48631-D56C45E4 for ; Wed, 24 Aug 2011 05:37:36 -0400 Received: from akdesk ([192.168.0.40]) by akbkhome.com with esmtpa (Mailfort v1.2) (envelope-from ) id 1Qw9tp-0003iP-14 for internals@lists.php.net; Wed, 24 Aug 2011 17:37:29 +0800 Message-ID: <4E54C658.6070209@akbkhome.com> Date: Wed, 24 Aug 2011 17:37:28 +0800 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11 MIME-Version: 1.0 To: internals@lists.php.net References: <1314115682.2635.98.camel@guybrush> <4E545A6C.60704@akbkhome.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-mailfort-sig: 371f0f753c7c0c905f14f1ea64ec5745 Subject: Re: [PHP-DEV] PHP 5.3.8 Released! From: alan@akbkhome.com ("alan@akbkhome.com") Since when has changing documented behaviour and breaking a large number of applications been acceptable? (Well, happens occasionally by accident ..) This was a 'feature change' to is_a(), it was documented as _only_ returning 'TRUE' when an object was passed as the first object and it was an instance of that... I did read through the previous posts, (just caught up the other day), it looks like if anybody really need to do what this new feature provides, (which is probably very rare), then $left == $right || is_subclass_of($left,$right) should work fine without 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, alan@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 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.. >> > from what I understand, this won't be changed, as the current behavior > is correct, the old was a bug: > > as Stas pointed out: > "Not a bug. $var is interpreted as a class name. To know if one class > extends another, the class in question (first one) should be loaded. > There's no need to load the second one since if it's unknown nothing > can be instance of it and existing classes can not extend it." > if you used this previously > > from Dmitry: > "Before the patch, is_a() didn't accept string as the first argument > at all, so it always returned "false" and never triggered > __autoload(). The proposed patch didn't revert to original behavior. > It just disables autoloading and may lead to wrong result. > > class a {} > class b extends a {} > var_dump(is_a("b", "a")); // it was false before 5.3.7, now it's true > > I would say that the old behaviour was wrong, especially because > "instanceof" and is_subclass_of() already implemented support for > string arguments." > > so your example was bogus, as passing a non-object as a first > parameter wasn't supported (see http://php.net/is_a) so your code > example depends on an undefined behavior and results in a bogus result > (is_a() alwas returned false if you passed a non-object) > > so in a way it is really a BC, but I think that this change is really a bugfix. >