Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55494 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 41230 invoked from network); 17 Sep 2011 21:55:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Sep 2011 21:55: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 67.192.241.113 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.113 smtp113.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.113] ([67.192.241.113:36086] helo=smtp113.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id EC/AA-05466-957157E4 for ; Sat, 17 Sep 2011 17:55:38 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 4CA0824032B; Sat, 17 Sep 2011 17:55:35 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id D51FF2402CD; Sat, 17 Sep 2011 17:55:34 -0400 (EDT) Message-ID: <4E751756.2020400@sugarcrm.com> Date: Sat, 17 Sep 2011 14:55:34 -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: "RQuadling@GMail.com" CC: PHP internals References: 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/17/11 2:39 PM, Richard Quadling wrote: > An interface is the absolute here. Sub classes (the super class being > abstract or otherwise), should be able to define MORE parameters (with > or without default values). Otherwise they aren't extending, but > implementing - and for me that's the role of an interface. No, this is not correct. Requiring more parameters, despite seeming like "extending", is actually not extension but additional restriction - if you had function with 1 param, you could call it as foo(1) or foo(1,2) (in the second case 2 would be ignored) but if you add second parameter now only foo(1,2) works. The new method is more restrictive than the old one, and that shouldn't happen in proper OO. > It is only interfaces that guarantee things because the interface IS > the guarantee. > > A class isn't beholden to anything it inherits. You can override > methods, completely obscuring the super class if you so want. This is a wrong thing to do and should be avoided at all costs. Or, putting it other way, if you want to do this, do not use inheritance, it's not for that. By using inheritance, you agree to a contract that says "this class is at least as good as the base class, but maybe also better". Violating this contract is setting yourself up for all kinds of trouble. > A subclass can completely divorce itself from the superclass. It "can", technically, but it should not. Of course, we can not control it, except for most basic cases, but at least in basic cases we can. Now, I have absolutely no idea where separate treatment of abstract and non-abstract classes came from - can anybody explain that (preferably people that actually implemented that)? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227