Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52400 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 28656 invoked from network); 16 May 2011 18:30:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 16 May 2011 18:30:37 -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.153 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.153 smtp153.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.153] ([207.97.245.153:46270] helo=smtp153.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id A5/5F-26716-C3D61DD4 for ; Mon, 16 May 2011 14:30:36 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp25.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id AFDCC300C88; Mon, 16 May 2011 14:30:17 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp25.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 4C6833008AB; Mon, 16 May 2011 14:28:48 -0400 (EDT) Message-ID: <4DD16CDF.2090007@sugarcrm.com> Date: Mon, 16 May 2011 11:28:47 -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: Andrew Curioso CC: "internals@lists.php.net" References: 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! > A fatal error is thrown if you try to call parent::__construct() from a > subclass > of SplObjectStorage. I'm thinking maybe it'll be useful to make parent::__construct silently succeed if parent class exists but has no ctor. The reason for that that for many classes you _have_ to call parent ctor for normal functionality, on the other hand some of them may not have it clearly documented if ctor method exists or not. Also, even if ctor method doesn't exist in fact there's always default empty one (since you can create object without explicitly writing a ctor). So, if we allow parent ctor always succeed it will make the code more robust. What do you think? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227