Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55560 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 89079 invoked from network); 20 Sep 2011 17:40:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Sep 2011 17:40:51 -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:52926] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BB/B0-18228-220D87E4 for ; Tue, 20 Sep 2011 13:40:50 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B872B29A75F; Tue, 20 Sep 2011 13:40:47 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp14.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 2C5A929A74F; Tue, 20 Sep 2011 13:40:45 -0400 (EDT) Message-ID: <4E78D01C.6040909@sugarcrm.com> Date: Tue, 20 Sep 2011 10:40:44 -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: Gustavo Lopes CC: "internals@lists.php.net" References: <4E74E5A0.2030006@sugarcrm.com> <4E76320F.6010904@sugarcrm.com> <4E764137.9080507@sugarcrm.com> <4E7708FA.7080802@sugarcrm.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] __constructor parameter limitations. From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! On 9/19/11 2:32 AM, Gustavo Lopes wrote: > The thing if you introduce func_get_args() to the argument, any discussion > about enforcing signatures becomes meaningless. One could argue this > should be allowed: > > class A { > function foo() {} > } > > class B extends A { > function foo($a) {} > } No, this can not be allowed because A's signature accepts any call, including foo(), but B's only accepts one with at least one parameters, so LSP is broken here. That is regardless of what A::foo() is doing inside, since arguments are going to be checked first. Having said that, even in this case I would probably not go as far as producing a fatal error - though E_STRICT would be OK here. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227