Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:54889 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 90828 invoked from network); 24 Aug 2011 20:21:54 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Aug 2011 20:21:54 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.143 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.143 smtp143.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.143] ([67.192.241.143:48039] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9B/00-24735-06D555E4 for ; Wed, 24 Aug 2011 16:21:53 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 62F0329A57F; Wed, 24 Aug 2011 16:21:50 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp14.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id EB4CD29A576; Wed, 24 Aug 2011 16:21:49 -0400 (EDT) Message-ID: <4E555D5D.3090101@sugarcrm.com> Date: Wed, 24 Aug 2011 13:21:49 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: Pierre Joye CC: "alan@akbkhome.com" , "internals@lists.php.net" References: <4e553b46.843cdf0a.0d43.4d1a@mx.google.com> <4E553CA5.4050401@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] PHP 5.3.8 Released! From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 8/24/11 11:05 AM, Pierre Joye wrote: > As it was working perfectly fine until now, it was perfectly fine to > use is_a only to valid possible instances of a given class, passing a > non object returned false, which was totally correct (per se). I think you are confusing "worked for me" with "perfectly fine". Like calling file_exists on an array argument and relying on the fact that file by the name "Array" does not exist (it doesn't work this way, but could have worked in some old version). This is not a correct usage, it is just by chance does what you intended. Passing invalid arguments to a function and relying it would work properly is not a good idea. > Now call that a bug, fine, but it is a breakage in a patch release. In general, I do not think we can promise bug compatibility, and shouldn't encourage people to expect it. In this particular instance, we may or may not make an exception, depending on how important is to have is_a work with strings. If we leave strings functionality in, autoloading should be a part of it, it's the only way it makes sense. But we could as well not include string support for is_a() in 5.3, it's not a critical fix IMHO. > About why it should not suddenly changes this working perfectly fine > before. And about not calling autoload. It did not work "perfectly fine" before. This code relied on a buggy undocumented behavior, in no universe it is "perfectly fine". -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227