Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52044 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 39236 invoked from network); 28 Apr 2011 08:23:07 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Apr 2011 08:23:07 -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 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:44431] helo=smtp143.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id BA/12-28716-AE329BD4 for ; Thu, 28 Apr 2011 04:23:07 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp24.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id B28A61801D1; Thu, 28 Apr 2011 04:23:03 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp24.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 3C8331801A5; Thu, 28 Apr 2011 04:23:03 -0400 (EDT) Message-ID: <4DB923E6.3020307@sugarcrm.com> Date: Thu, 28 Apr 2011 01:23:02 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Ferenc Kovacs CC: Felipe Pena , internals References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] [RFC] Return type-hint From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! >> http://wiki.php.net/rfc/returntypehint > for the upcoming 5.4 release, I think it would be extremely useful, even > without the scalar stuff. Personally, I see even less point in having strict return typing (please stop using "hint" terminology, it confuses the whole matter, it's not "hint" if it describes mandatory restriction on the data) than strict argument typing. The RFC doesn't explain it either beyond "here how you can have some nice errors". But why would I want to see these errors? How they would make anything easier or better? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227