Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:61175
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain lerdorf.com from 209.85.160.170 cause and error)
Message-ID: <4FFF0584.6080708@lerdorf.com>
Date: Thu, 12 Jul 2012 10:12:36 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: Anthony Ferrara <ircmaxell@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAAyV7nGwONAwPRRYLKswJtR-1RsrhQc5yS+dVuyZr1BHBW_NBA@mail.gmail.com> <4FFEFBB3.7090507@sugarcrm.com> <4FFEFD81.6020404@lerdorf.com> <4FFEFF71.2060202@sugarcrm.com>
In-Reply-To: <4FFEFF71.2060202@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Iterable Type Hint
From: rasmus@lerdorf.com (Rasmus Lerdorf)

On 07/12/2012 09:46 AM, Stas Malyshev wrote:
> Hi!
> 
>> For non-interchangeable types it is already strict by definition. I
>> don't see a problem with type hints that make life easier on both the
>> caller (by generating better error messages) and the callee (by having
>> to write less boilerplate type verification code).
> 
> It doesn't make the life of the caller easier. On the contrary, it makes
> each call into a minefield - will it blow up with a system-level error
> when you call it? Added bonus of this one is that there's no sure way to
> check for it - at least for callable we had is_callable, here we just
> have to add boilerplate code for every call. And good luck making them
> handle it in an unified way - since it's not library code, then probably
> will do each different thing, and about 50% of places will forget it or
> not know downstream inserted this surprise into the execution stream.

For non-interchangeable types the code is going to blow up anyway. If
you pass a MySQL resource to a function that takes a callable and that
function does $arg(); the result is a non-catchable fatal error:

Fatal error: Function name must be a string

Compare to adding 'callable':

Catchable fatal error: Argument 1 passed to func() must be callable,
resource given

This gives quite a bit more info since we now know that it was an
argument and specifically which argument it was, what its type was and
what it should have been vs. having a fatal from somewhere deep in the
function itself. So I disagree with you on it not making life easier for
the caller in this specific case where there is no way for the type to
be coerced into something that makes sense.

-Rasmus