Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52409 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 45545 invoked from network); 16 May 2011 19:45:22 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 May 2011 19:45:22 -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.203 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.203 smtp203.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.203] ([207.97.245.203:47624] helo=smtp203.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7B/52-26716-1DE71DD4 for ; Mon, 16 May 2011 15:45:22 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp40.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 8ACF635021C; Mon, 16 May 2011 15:45:19 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp40.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 13E9C350385; Mon, 16 May 2011 15:45:18 -0400 (EDT) Message-ID: <4DD17ECD.4070505@sugarcrm.com> Date: Mon, 16 May 2011 12:45:17 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: Anthony Ferrara CC: "internals@lists.php.net" References: <1305570720.1344.535.camel@guybrush> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Inconsistencies with constructors in SPL From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > Well, if we follow that logic (which does make sense), then shouldn't > all magic methods be implicit? So parent::__sleep/__call/__get/etc > would silently do the default if not defined? In most cases, you are required to call parent ctor, but there's no such requirement for other methods. Ctors are special in a way that in 99.9% of cases you do call parent ctor. I can't really think of any case where you don't want to do this. Ctors are special (well, along with dtors, but those aren't used as much). In fact, Java, for example, always inserts parent ctor call if you don't have one and defines empty ctor so it always works. Of course, we don't have to follow them but this shows this pattern is known. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227