Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:59785 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 99656 invoked from network); 12 Apr 2012 05:24:16 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 12 Apr 2012 05:24:16 -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.163 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.163 smtp163.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.163] ([67.192.241.163:53963] helo=smtp163.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 5E/B3-23245-FF6668F4 for ; Thu, 12 Apr 2012 01:24:16 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp6.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 51E392709F6; Thu, 12 Apr 2012 01:24:13 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp6.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id B4D43270903; Thu, 12 Apr 2012 01:24:12 -0400 (EDT) Message-ID: <4F8666FB.4070802@sugarcrm.com> Date: Wed, 11 Apr 2012 22:24:11 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:11.0) Gecko/20120313 Thunderbird/11.0 MIME-Version: 1.0 To: Galen Wright-Watson CC: "internals@lists.php.net" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Access by siblings of (abstract) protected methods From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > In summary: should abstract protected constructors be inaccessible by > siblings, as is true of __clone and __destruct? Should __construct, __clone > and __destruct always be accessible in relatives, as is true of other > methods? Depending on the answers, there could be a documentation issue, or > bugs. OK, I checked why ctor behaves differently, and it's because parent ctor is considered to be prototype for child ctor (with signature enforcement, etc.) only if it's declared abstract or brought from the interface. So, by declaring ctor as abstract or making it part of the interface, you make it part of the contract and thus accessible to all hierarchy. If you do not do that, ctors are completely unrelated to each other (this is different for all other non-static methods) and thus having parent ctor doesn't say anything about child ctor, so parent ctor's visibility does not carry over. So for ctor is not a bug. I still think it's most probably a bug for __clone and __destruct. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227