Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:49171
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zend.com designates 212.25.124.185 as permitted sender)
Message-ID: <7.0.1.0.2.20100729151449.0f884440@zend.com>
Date: Thu, 29 Jul 2010 15:17:57 +0300
To: internals@lists.php.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Fwd: Re: [PHP-DEV] Type hinting
From: zeev@zend.com (Zeev Suraski)

With the revived interest in the neighbourhood of type hints in the 
last few days I'm resending this email from a few weeks ago.

In a nutshell, use auto-conversion for scalar type hints, and modify 
the conversion rules throughout PHP to handle 'senseless' conversions 
that result in data loss differently - by emitting E_TYPE.

Zeev

>Date: Wed, 9 Jun 2010 17:17:13 +0300
>To: Daniel Convissor <danielc@analysisandsolutions.com>
>From: Zeev Suraski <zeev@zend.com>
>CC: PHP Internals List <internals@lists.php.net>
>Subject: Re: [PHP-DEV] Type hinting
>
>At 02:59 09/06/2010, Daniel Convissor wrote:
>>Hi Lukas:
>>
>>On Fri, Jun 04, 2010 at 08:28:12AM +0200, Lukas Kahwe Smith wrote:
>> >
>> > Same deal as E_NOTICE. Either you care about them or you dont.
>>
>>Exactly.  The type hinting situation is unique.  It is something that
>>applications will frequently want to handle gracefully in order to
>>provide useful error messages.  A new error level is needed, as is an API
>>/ function to obtain the failed parameter names, desired type and passed
>>type.
>
>Daniel,
>
>I think having E_TYPE (or whatever), a non-fatal notice that can be 
>either ignored or handled separately from everything else makes 
>sense.  I think we may actually want to introduce it at the most 
>basic levels of PHP, so that whenever data loss occurs (except for 
>explicit casts) - an E_TYPE warning will be generated.  That will 
>bring consistency between the new type hinting and the rest of PHP.  Thoughts?
>
>Dmitry prepared a patch that implements auto-converting type hinting 
>with silent data loss.  If we combine it with an 
>infrastructure-level E_TYPE upon data loss - I think we have a 
>pretty good solution overall.  The patch is available at 
><http://wiki.php.net/rfc/typecheckingstrictandweak>http://wiki.php.net/rfc/typecheckingstrictandweak 
>
>
>Regarding having an API that allows you to access the original 
>unconverted value and/or its type - I don't think we should go in 
>that direction.  Presently this information is not retained in any 
>way, and retaining it would be quite a headache and we'll also incur 
>a performance penalty.  If you're going to be using APIs to 
>determine what happened to a passed argument and behave accordingly 
>-  why not simply avoid using type hinting, and perform type/value 
>checks in the function body instead?
>
>Zeev
>
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php