Sebastian Bergmann wrote:
Am 12.08.2010 10:31, schrieb Derick Rethans:
Well, PHP wouldn't support it directly. But it would allow a zend
extension like Xdebug to provide a strict validation function while
debugging and development. Very similar to the overloaded zend_error_cb
and var_dump() function. During production you'd obviously *not* have a
caster/strict type validator.
Sounds reasonable to me.
It's funny how you and Derick agree on this, just as I've finished a new
tool which doesn't implement the exact functionality (certainly not in
the PHP core), but uses Xdebug and PHPUnit to perform parameter type
verification.
You could call it an in-between solution between the current situation,
where we have no scalar type hinting, and the proposed type hinting
solution that was discussed in the past few weeks, with an added benefit
that it doesn't require PHP core changes and doesn't cause any
production performance degradation.
Basically, I got fed up with developers writing functions with
ever-changing parameter types, parameter order and return types, causing
unit tests to fail (best-case) or untested code to fail (worst-case).
Short example (crappy code, without error handling) :
- We have a CSV formatted data file, generated from an external source,
that we need to process (fields are : employeeId, firstname, lastname,
wage, pay) :
1, Claire, Clarckson, 2900, 1
2, Tom, Whitney, 1932, 1
4, Jules, Verne, 2131, 0
6, Gregory, Jameson, 2143, 1
- People with 'pay' set to 1 should be paid. So we have some code :
public function processFile($filename)
{
$data = file($filename);
foreach ($data as $line) {
processLine($line[0], $line[3], $line[4]);
}
}
public function processLine($employeeId, $wage, $pay)
{
if ($pay) {
sendPayCheck($employeeId, $wage);
}
}
- Not the best code, but it's the kind of code you see everywhere. And
it will work just fine, until someone decides to export the data like this :
1, Claire, Clarckson, 2900, true
2, Tom, Whitney, 1932, true
4, Jules, Verne, 2131, false
6, Gregory, Jameson, 2143, true
- From that point onwards, everyone will be paid, since the string
"false" is boolean true.
- If you wrote unit tests to test the above code with some sample
(non-live) data you keep in a file (which is the case for most mock
tests), they will still pass, since they don't anticipate the changing
format.
- We should probably validate the incoming data, but as I said this is
an example to illustrate the type of issues that exist.
This is where my little PHPUnit addon comes in : it uses Xdebug's trace
functionality to verify if the parameters being passed to and returned
from a function/method are of the same type as the one(s) specified in
the docblock.
The advantages of doing this are :
- Verification that you're not passing data with different data types
than the one expected
- Verification that the docblock is correct (a developer might have
changed code, but forgotten to update the docblock), so your API docs
will be consistent
- You can actually rely on the correct type being passed to your
function, which basically means that, if everyone inside your company
uses this tool, you can get rid of tons of is_bool, is_int, etc tests
that a lot of people build into their code now (except when using
external data sources)
Having some level of type validation can greatly improve consistency and
stability, especially for libraries that are used across multiple
projects. We use the same base library for each project and usign this
addon we have discovered a few issues with incorrect type usage, one of
which explained an elusive bug.
Anyways, for those of you interested in checking it out :
- I made a github fork on the PHPUnit project :
http://github.com/wimg/phpunit
- If you want to verify return types, you will need an Xdebug patch :
http://xdebug.org/archives/xdebug-general/1870.html (hoping Derick will
include it in the next Xdebug release)
- More information about the whole addon --> see my blog post here :
http://techblog.wimgodden.be/2010/08/15/using-phpunit-to-verify-parameter-types-revisited/
Looking forward to any feedback !
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
