On Thu, 2010-05-27 at 06:59 -0400, Ilia Alshanetsky wrote:
> As far as your example goes consider a function that expects a boolean, but
> instead gets an int/string/float, which in nearly all cases will result in
> TRUE. Which is not the desired outcome.
Especially the int to boolean conversion is a really useful one in many
cases, in my opinion. Often enough one uses integers as as flags. For
instance with bit operations.
I consider
function do_something(bool $report_error) {
/* ... */
}
do_something(error_reporting() & E_NOTICE);
absolutely legitimate.
And I think that it will hurt quite a bit if we force our users to take
care of their types. Usually a user doesn't have to care about the fact
that most databases return strings for all returned data. The database
ensures it's a numeric value in a specific range (that's why they are
using relational databases...) and that's all most users care about.
It's numeric and can be printed as string. Enforcing this can have quite
strange results users might not think about:
PDO_mysql allows an emulation of prepared statements. If that emulation
is being used all data will be returned as strings. Now people can turn
of this emulation and use native prepared statements. In that case the
data coming from MySQL's binary protocol will be put in properly typed
zvals. Now assume a library is using PDO with native prepared statements
and places "type hints" everywhere. At some point in time a user decides
that the additional roundtrip hurts and turns on emulation. Suddenly all
code will break. Fun.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
