Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55563 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 95419 invoked from network); 20 Sep 2011 18:25:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Sep 2011 18:25:37 -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 207.97.245.163 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.163 smtp163.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.163] ([207.97.245.163:35730] helo=smtp163.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 76/E1-18228-0AAD87E4 for ; Tue, 20 Sep 2011 14:25:36 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp46.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 4672EE8660; Tue, 20 Sep 2011 14:25:33 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp46.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 7D3ABE82F8; Tue, 20 Sep 2011 14:25:32 -0400 (EDT) Message-ID: <4E78DA9B.7060606@sugarcrm.com> Date: Tue, 20 Sep 2011 11:25: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: Anthony Ferrara CC: "internals@lists.php.net" References: <4E768C86.3030307@sugarcrm.com> <4E769418.6040200@sugarcrm.com> <4E770163.2090001@sugarcrm.com> <4E770770.60809@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/19/11 7:26 AM, Anthony Ferrara wrote: > that point, why even bother with interfaces? The interface defines > what should be accepted, and any method that implements it should > accept exactly that (no more, no less, no different). Otherwise Here you lost me. Why exactly you can not accept more? If you implement some interface, and fulfill all obligations about this interface, why can not you also accept more than this interface requires? This is certainly not the current practice - but even in theory, why would that be a requirement? LSP certainly does not require that - otherwise it would also say "any property that is not true for q(x) should also be not true for q(y)" - which btw would severely reduce what you could do in OO. > you'll violate the contract and couple to the implementation instead > of the interface. This causes the checked polymorphic ability of the > interface to go out the window. The result is that the interface > becomes completely useless. So, in order for interfaces to be useful, > they should include the exact arguments in order and in type, and the > runtime (PHP) should enforce that (which it does). I do not see why this would be true. You use interface for the protocol it defines, and it's useful for that, but you can also use extended protocol when you know particular implementation provides extended features. Yes, that would mean that this specific code would not work with all implementations of the base protocol - but that's exactly what you want, have guaranteed base and optional extension. Yes, that would introduce coupling - but sometimes you have no other way (think about something like PDO and having to support both base features and give access to additional DB-specific features for performance, etc.) I agree that it may be not ideal from purist point of view but practically I've seen many situations where it's required - especially when you can't really change the interface. Having said that, I could begrudgingly (very begrudgingly) accept the case for doing this with interfaces. The problem we have however is not with interfaces but with abstracts. > That's my $0.02. I say leave it as is. The way it is working right > now promotes good API design and makes difficult doing things that Unfortunately, it does not - in fact, as you yourself noted, abstract should allow child classes to generalize, but right now not only this is not allowed, but the presence of an abstract anywhere in the hierarchy blocks generalization for the whole hierarchy. So not only you have to work around this particular problem when you use abstract classes - you have to work around the case where somebody refactored base classes you relied on and introduced abstract signature there - and now your perfectly good and working generalization produces fatal errors! -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227