Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:52064 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 25041 invoked from network); 28 Apr 2011 17:45:41 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 28 Apr 2011 17:45:41 -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.163 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 207.97.245.163 smtp163.iad.emailsrvr.com Linux 2.6 Received: from [207.97.245.163] ([207.97.245.163:45886] helo=smtp163.iad.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 34/53-03888-2C7A9BD4 for ; Thu, 28 Apr 2011 13:45:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp26.relay.iad1a.emailsrvr.com (SMTP Server) with ESMTP id 53B04A85ED; Thu, 28 Apr 2011 13:45:36 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp26.relay.iad1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id 84BF3A863C; Thu, 28 Apr 2011 13:45:35 -0400 (EDT) Message-ID: <4DB9A7BE.6010307@sugarcrm.com> Date: Thu, 28 Apr 2011 10:45:34 -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: <4DB923E6.3020307@sugarcrm.com> 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! > I see many advantages of the introduction of return type hinting. > - you can guarantee that your methods returns only what is explicitly > stated (or else it blows up, the same as for arguments) You can't, because function resolution happens in runtime, so the only point you know what the function called "foo" returns is the moment where you're already calling it, not a moment before. > - it can save you from having to define the return type in phpdoc, your > code can define it's behavior Why I need being "saved" from documenting my code properly? Anyway, the function code defines the behavior, declaration of return type just ensures function would fail in runtime if your code tries to return unexpected data - but how is it helpful? The client of this function doesn't even know that before actually calling it! > - I think maybe the language itself could use that information, for > performance, etc. improvements (we know that the return value will be That would need static compile-time binding of functions, which implies static binding of includes, etc. - basically, compiling PHP code as a whole in one monolitic application. > created runtime, but we can throw it away if it doesn't match the return > type or something), maybe we can use that information to throw errors on > compile time if we find a non runtime decided return value which doesn't > match with the return type. Sorry, what is "non runtime decided return value"? And how is "compile time" different from "runtime" in your opinion - when exactly that "compile time" happens? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227