Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:66731 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 29886 invoked from network); 20 Mar 2013 20:22:45 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 20 Mar 2013 20:22:45 -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.113 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.113 smtp113.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.113] ([67.192.241.113:42166] helo=smtp113.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3C/1E-46127-49A1A415 for ; Wed, 20 Mar 2013 15:22:44 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp21.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 83CC82404D3; Wed, 20 Mar 2013 16:22:41 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp21.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 9712D2404C0; Wed, 20 Mar 2013 16:22:26 -0400 (EDT) Message-ID: <514A1A7E.1050908@sugarcrm.com> Date: Wed, 20 Mar 2013 13:22:22 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Carlos Rodrigues 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] Method check - Can someone create a RFC for it? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > We've had a problem recently where one of our developers forgot an "if". We clearly have two contradicting directions here. On one hand, we have people that say giving '1' to a method expecting integer should be an error, and anything unexpected should generate warnings and errors because the code should handle exceptional cases explicitly. On the other hand, we have people who say "no matter what happens, just plow through and substitute nulls if something is wrong". Both approaches I guess have their advocates and their fans, and have good pro and contra arguments. What however I think can not be done is randomly taking both of these approaches in one language at a whim and expect it to make sense. PHP has taken enough criticism on this front and we don't need to add more to it. Either we say "if the call can't be done it's an error" or we say "if we can't call something we just return null" but not both. PHP currently treats methods that can't be called as an error. I think replacing it with "just return null" would not be a thing most PHP developers would want. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227