Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:31312 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 77344 invoked by uid 1010); 29 Jul 2007 08:07:02 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 77329 invoked from network); 29 Jul 2007 08:07:02 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Jul 2007 08:07:02 -0000 Authentication-Results: pb1.pair.com smtp.mail=stas@zend.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=stas@zend.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender) X-PHP-List-Original-Sender: stas@zend.com X-Host-Fingerprint: 63.205.162.114 unknown Windows 2000 SP4, XP SP1 Received: from [63.205.162.114] ([63.205.162.114:50731] helo=us-ex1.zend.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 92/00-11619-4AA4CA64 for ; Sun, 29 Jul 2007 04:07:02 -0400 Received: from [127.0.0.1] ([192.168.17.18]) by us-ex1.zend.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 29 Jul 2007 01:06:58 -0700 Message-ID: <46AC4A9B.9070704@zend.com> Date: Sun, 29 Jul 2007 01:06:51 -0700 Organization: Zend Technologies User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Will Fitch CC: 'Jeremy Privett' , 'Larry Garfield' , internals@lists.php.net References: <74.B1.05050.EADEC964@pb1.pair.com> <08.07.20814.2587AA64@pb1.pair.com> <46ABD596.3060005@zend.com> <200707281905.27822.larry@garfieldtech.com> <46abe6c8.4f99220a.6e0c.2bb5@mx.google.com> In-Reply-To: <46abe6c8.4f99220a.6e0c.2bb5@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2007 08:06:58.0456 (UTC) FILETIME=[6F945180:01C7D1B7] Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5? From: stas@zend.com (Stanislav Malyshev) > On one hand I agree, since PHP is so loosely typed. But it's hard to make > the argument that type-hinting return values is pointless, since PHP allows > (class) type-hinting with parameter values. I personally think type-hinting > is very nice, and not for the purposes of IDEs. The difference is that typehinting works this way: 1. I'm a library, I want to get type X for $foo 2. I put typehint, so I didn't need to check if $foo is X 3. If you pass not X to $foo, my code is going to tell you that you can't do that And return type works like that: 1. I'm a library writer that says foo() returns X 2. I have to use for it, since I don't use foo() 3. You're client, so you read the docs and see foo() returns X 4. You write code which supposes foo() always returns X 5. I decide these return types are more trouble than they are worth, and make foo() return false on error, removing return type. 6. Your code has no way to check I did that, so it's broken now. Basically, it sums up to documentation - if documentation isn't right (or if it changed and you didn't follow) your code is going to break and you have no way to prevent it. That's what you have now with @return - why add language construct? > If one of the best selling points of PHP is its typeless environment, then > why make any of these available? It appears that we are moving more and If it was up to me, I'd probably not bother adding input typehints either :) But as I said above, input typehints are significantly different from return types. -- Stanislav Malyshev, Zend Software Architect stas@zend.com http://www.zend.com/ (408)253-8829 MSN: stas@zend.com