Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:37305
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.162 as permitted sender)
Message-ID: <481747C1.1020302@zend.com>
Date: Tue, 29 Apr 2008 09:07:29 -0700
Organization: Zend Technologies
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Sam Barrow <sam@sambarrow.com>
CC: internals@lists.php.net
References: <1209137410.6642.9.camel@sbarrow-desktop>	 <20080425182341.GB14490@mint.phcomp.co.uk>	 <1209149047.20639.18.camel@sbarrow-desktop>	 <48122C14.7070705@omegavortex.net>	 <1209150944.20639.24.camel@sbarrow-desktop>	 <7dd2dc0b0804251224s750679acn169637efbd8653fa@mail.gmail.com>	 <1209151505.20639.25.camel@sbarrow-desktop>	 <e2e02fe0804251422k36dd56c6r71b1ce69401d42b6@mail.gmail.com>	 <20080425231305.GC14490@mint.phcomp.co.uk>	 <9484717D-2EC6-44FF-93C8-1A9911294AF6@bitxtender.com>	 <7dd2dc0b0804261524l22237b58tfb9d0a341ab77233@mail.gmail.com> <1209482524.3257.9.camel@sbarrow-desktop>
In-Reply-To: <1209482524.3257.9.camel@sbarrow-desktop>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Return type hinting patch
From: stas@zend.com (Stanislav Malyshev)

Hi!

> Well in summation I think this is something that should be implemented,
> I don't see any arguments against implementing this atleast for arrays
> and classes, like we already have for function parameters.
> 

I think we had plenty of arguments against it last time it was 
discussed. You could see it here for example:
http://marc.info/?l=php-internals&m=118478789527042&w=2
But I can repeat.

Return types are useful in statically compiled languages, since they 
enable static type control. Since PHP has no static type control, return 
type is useless for the function client - the fact that function returns 
type X itself can be found in the documentation (where it belongs) - 
that includes PHPDoc for the smarter IDEs out there - but code-wise 
there's no useful action I can take using this information that I can't 
take using just what function actually returns and be safer.

Return type definition can prohibit function from returning different 
types, however here we have two problems. First is that function 
definition and code is usually written by the same person in the same 
(very small) context, and this person has to be somewhat absent-minded 
to forget what function returns from definition to return a dozen lines 
below. Supporting such absent-mindedness with language constructs 
doesn't appear appropriate. Second is that only action return type 
definition could take in this case is break the application in runtime, 
which would be of little help to our absent-minded function writer and 
especially to its client.

But even worse, since on the client side you have no way to enforce this 
restriction, you can't even rely on it in any context - what if the 
absent-minded function writer forgot to put the type restriction? If the 
type was important for you, you'd have to check it anyway, since you 
have no way to enforce the restriction on the client side! Since your 
enforcement on one side and your usage of the data is on the other, the 
enforcement is unreliable and thus useless.
-- 
Stanislav Malyshev, Zend Software Architect
stas@zend.com   http://www.zend.com/
(408)253-8829   MSN: stas@zend.com