Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:31006 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 19425 invoked by uid 1010); 17 Jul 2007 16:26:26 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 19409 invoked from network); 17 Jul 2007 16:26:25 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 17 Jul 2007 16:26:25 -0000 X-Host-Fingerprint: 136.159.238.143 pc143-238.admin.ucalgary.ca Received: from [136.159.238.143] ([136.159.238.143:18266] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 74/B1-05050-EADEC964 for ; Tue, 17 Jul 2007 12:26:23 -0400 Message-ID: <74.B1.05050.EADEC964@pb1.pair.com> To: internals@lists.php.net Date: Tue, 17 Jul 2007 10:26:18 -0600 User-Agent: Thunderbird 2.0.0.4 (Windows/20070604) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 136.159.238.143 Subject: Type-hinted return values in PHP5? From: david.nqd@gmail.com (David Duong) Hello everyone, I'm emailing to this list to suggest that "support for type-hinted return values"[1] be in added in PHP 5.y.x instead of PHP 6. Conceptually, this is the second half of "type-hints" already introduced in PHP 5. This is why: When a programmer is designing an interface (the language construct), only what is accepted by the interface can be defined. Calling code is left with no idea of what the return type is going to be. Even with great documentation, when designing an interface, it would be great to be able to take the responsibility of type checking return values from calling code onto the interface. To design a full interface, the interface designer should be able to say that a caller can call method X with input types Y and Z, then expect an object that implements interface Z to be returned. The caller should not have the responsibility of handling any other return types. I'm looking forward to many of the upcoming features of PHP6, but PHP 6 is far from being stable (?). This is a change will break any existing code and is not a big extension on how PHP, a weakly typed language (not necessarily a bad thing), handles types. [1] http://oss.backendmedia.com/PhP60 ps - please let me know if posts like these should be posted elsewhere Thanks, David N. Q. Duong