Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:44640
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ilia.ws designates 209.85.222.198 as permitted sender)
Cc: PHP Internals <internals@lists.php.net>
Message-ID: <37C0AA98-832D-4B62-A277-B0DF470576B3@ilia.ws>
To: Stanislav Malyshev <stas@zend.com>
In-Reply-To: <4A4C61A1.1090602@zend.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Thu, 2 Jul 2009 08:42:37 -0400
References: <af54caaf0907011935nbd701eeldcfc79debca1b967@mail.gmail.com> <C271BFE2-D286-427E-9848-A134ADCD80CF@ilia.ws> <4A4C61A1.1090602@zend.com>
Subject: Re: Flexible type hinting
From: ilia@ilia.ws (Ilia Alshanetsky)


On 2-Jul-09, at 3:28 AM, Stanislav Malyshev wrote:

> Hi!
>
>> 2) Type hinting will not create a mess of cast to the right types  
>> in the code as Stas had suggested, in close to a million lines of  
>> PHP code we have, I've been able to find less then 1000 (just did a  
>> grep) instances of casts. There is a good reason for that once you  
>> get out of the input processing stage you typically (aside from  
>> __toString()) have the data in the right type. The code also  
>> includes bits from PEAR and external
>
> The problem here is that if you want to write a robust code that  
> wouldn't randomly fail at runtime "typically" isn't good enough

If it fails it means some funciton did not return the expected value  
and that's a problem, not something that should be ignored if you  
decided (if you don't want to use, then things remain as they are) to  
use type hinting.

> - since wrong type is supposed to be a fatal error (which one could  
> not handle in the typehinted library code since it happens on the  
> client side before your code takes control), you would want to  
> ensure that would never happen when you call a typedhinted function.  
> And there's only two ways to do it - either make absolutely all  
> functions and variables that interact with typehinted functions to  
> be strict-typed (which we don't plan do) or do casts on each call to  
> hinted function. I do not see how anything else could produce robust  
> code provided that type mismatch is a fatal error and variables can  
> not carry type.
>
>> "stock php" for people to use. But please, don't reject this idea  
>> because you personally don't see yourself using it or because you  
>> want
>
> Being a C programmer for... hmm... about 20 years now I think I  
> don't have too much problem with strictly typed languages :) I just  
> think doing it in PHP the way you want to do it is going to produce  
> a lot of issues that people tend to under-appreciate when they cheer  
> the new cool feature.
>
> Also, looking at the patch I think it doesn't cover the matter of  
> inheriting the typehinted methods - i.e. if there's a typehinted  
> method, could I override it with non-typehinted version or vice  
> versa? What about typehinted interfaces?

Which is fine, because some people can use that functionality to  
overload methods they don't want to be type hinted from external libs  
the may be using.