Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55506 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 66457 invoked from network); 18 Sep 2011 23:59:34 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Sep 2011 23:59:34 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; 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:54837] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6F/B4-28880-2E5867E4 for ; Sun, 18 Sep 2011 19:59:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp4.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 4B6BC3A032F; Sun, 18 Sep 2011 19:59:28 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp4.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 88F613A0335; Sun, 18 Sep 2011 19:59:27 -0400 (EDT) Message-ID: <4E7685DE.6010805@sugarcrm.com> Date: Sun, 18 Sep 2011 16:59:26 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2 MIME-Version: 1.0 To: Pierre Joye CC: PHP internals References: <4E74E5A0.2030006@sugarcrm.com> <4E76320F.6010904@sugarcrm.com> <4E764137.9080507@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] __constructor parameter limitations. From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 9/18/11 4:21 PM, Pierre Joye wrote: > The key word missing here is "compatible". We enforce (or should) > compatible signatures. And that makes totally sense. foo() is compatible with foo($a, $b) - since anywhere you can call function declared as foo($a, $b) you can also successfully call one declared as foo(), it'd just ignore extra parameters - but it is not allowed (I gave an example). It was bad when it was a useless E_STRICT, it is much worse when it's a fatal error. > Are you saying that extending a class and making the constructor > incompatible with the extended class is a good thing to allow and to > do? If yes then I'd to strongly disagree with this idea as it allows I never said anything about constructor being "incompatible" with extended class and it being good thing. I am saying rejecting compatible but not matching signatures - and I gave example of foo() vs foo($a, $b) - makes no sense. And not even with E_STRICT - it's a fatal error now! > And finally, the reason why abstract differs from the other areas is > that they are newer. It was decided not to break BC for the other > cases where we should have done the same. While Marcus wanted to do it > everywhere, with the same good reasons. I guess "all abstracts do that" is better than "abstracts except for ctors do that" but only marginally as both behaviors make little sense to me. Being restricted to abstracts limits the BC impact (as people could just remove the abstract keyword and thus avoid trouble relatively easily) but in both cases it doesn't look too good. I'm not sure if we should keep the new BC-breaking error in 5.4 for consistency sake (I'd felt much easier if we had discussed that before - or we did and I just forgot?), but I seriously think we need to rework it in 5.5 and make all compatible signatures work without complaining. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227