Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:55562 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 91844 invoked from network); 20 Sep 2011 17:50:32 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Sep 2011 17:50:32 -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:39492] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/51-18228-862D87E4 for ; Tue, 20 Sep 2011 13:50:32 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp14.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 0C52E29A78E; Tue, 20 Sep 2011 13:50:29 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp14.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id CE57629A782; Tue, 20 Sep 2011 13:50:27 -0400 (EDT) Message-ID: <4E78D263.6070106@sugarcrm.com> Date: Tue, 20 Sep 2011 10:50:27 -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: Gustavo Lopes , "internals@lists.php.net" References: <4E764137.9080507@sugarcrm.com> <4E7685DE.6010805@sugarcrm.com> <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 3:20 AM, Pierre Joye wrote: > If we talk about implementing the abstract concept and we use the > interface model to do it, then we do it wrong. I'm out of other > arguments, or maybe one new one, if we implement abstract like > interface, then let kill abstract support, we don't need that. Interface defines protocol without any implementation. Abstract class defines both class template and protocol with partial implementation. These are different things, and regardless of signature discussion - which really has nothing to do with the difference between abstracts and interfaces - one of them does not replace the other in any way. You could simulate abstracts with interfaces, but that would be abuse of the interface idea. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227