Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:31307
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 63.205.162.114 as permitted sender)
Message-ID: <46ABD596.3060005@zend.com>
Date: Sat, 28 Jul 2007 16:47:34 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: David Duong <david.nqd@gmail.com>
CC:  internals@lists.php.net
References: <74.B1.05050.EADEC964@pb1.pair.com>	 <CF.02.04735.EAD6E964@pb1.pair.com> <98b8086f0707181255q2d338920o741d75b049efb4f7@mail.gmail.com> <469FA4AE.8000905@zend.com> <08.07.20814.2587AA64@pb1.pair.com>
In-Reply-To: <08.07.20814.2587AA64@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5?
From: stas@zend.com (Stanislav Malyshev)

> It would give you similar benefits to input type hinting, but instead of 
> "Functions are now able to force parameters to be objects...", it would 
> also read "Calling functions are now able to expect return types to be 
> objects...". If a function was defined to return object Z, but instead 
> returned false, then obviously there is something wrong and it could be 
> caught before calling code sees it expecting it to be something else.

Catching language-level error in application code is usually harder than 
just handling it in user code. And if you are talking about distinction 
between false/null and actual object, language level is the wrong level 
to catch such things.
If you handle the error in runtime, you could have the check as well. If 
you don't, the script breaks anyway, so it is not going to help you much.
Even more, the return value is the product of the module code, while 
input values are product of the outside code. So when you say "I'm going 
to process only type X, and I make a requirement for others to pass only 
X to me", it makes for me more sense than saying "I'm going to return 
only type X so I'm making restriction for myself to return only type X". 
The latter is more like declaring variable types, which have its 
functions in compiled languages but usually is not happening in dynamic 
interpreted languages.
Also, since from the client side there's no way to check if the function 
you are calling actually does have the return type restriction, it's 
quite hard to program basing on that from the client side. So you 
actually check it in one place (library) and use it in entirely 
different place (client) which is usually bad idea since the client 
becomes too reliant on internal details of the library.

> If I, or someone else decided to make a patch for this, and assuming it 
> worked exactly like I described, would it be accepted?

I don't know... I personally don't see much use for it, but others may 
disagree.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com