Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55503 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 36939 invoked from network); 18 Sep 2011 19:06:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 18 Sep 2011 19:06:38 -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 207.97.245.183 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.183 smtp183.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.183] ([207.97.245.183:34056] helo=smtp183.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 01/01-28880-C31467E4 for ; Sun, 18 Sep 2011 15:06:37 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp28.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id E9C41E0129; Sun, 18 Sep 2011 15:06:33 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp28.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D79B3E0213; Sun, 18 Sep 2011 15:06:32 -0400 (EDT) Message-ID: <4E764137.9080507@sugarcrm.com> Date: Sun, 18 Sep 2011 12:06:31 -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: Nikita Popov CC: Derick Rethans , "RQuadling@GMail.com" , PHP internals References: <4E74E5A0.2030006@sugarcrm.com> <4E76320F.6010904@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 11:23 AM, Nikita Popov wrote: > I didn't see any complaints about this "feature", so I don't really > see a reason why we should break BC with 5.3 here and drop the error > message. There's no matter of "breaking BC" - there's no BC issues with dropping error messages, nobody's code relies on generating fatal errors for specific code. > I already tried to explain why it makes sense: An abstract method is > much like an interface. Both define signatures without implementation. > If their signatures weren't enforces, what would abstract methods be > good for? An abstract method (for me) is a way for an abstract class What's the point of "enforcing" such signatures? The only point I know is that you could call these methods with specific parameters and have it work. In the example it is possible. Enforcing for the sake of enforcing is meaningless purism, which does not bear any practical purpose. Abstract methods define a contract between designer of the base class and implemetor of the concrete class. However, I do not see why this contract should state that you can never relax restrictions on your methods or ignore parameters or accept more than base class would allow you to accept. > to tell you: I need this and that method accepting these and these > arguments to work correctly. If the signature isn't enforced, this > doesn't make sense anymore. You could just as well drop the signature > from abstract method definitions, as it's pointless then. No it is not. The signature tells "this method would accept certain arguments". If you call it with these arguments, it would work. However, there's no promise to never extend the cases where it works - it goes contrary to the whole point of OOP to say "I will never loosen preconditions on my methods". -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227