2015-02-23 16:32 GMT-03:00 Marc Bennewitz <dev@mabe.berlin>:
> Hi all, > > Because the feature freeze for PHP 7 is near I like to know your thoughts > about one more change in passing arguments. Sure this one would introduce > one more deprecated message / BC break but this one s for reducing BC break > in the future! > > Currently a caller can pass undefined arguments as much he like. Such > passed arguments are only visible by the callee using > func_get_args/func_num_args but the need for such function definitions has > been gone with argument unpacking feature. The other rare possibility for > ignoring passed arguments by callables from functions like array_walk has > been gone, too, with the introduction of clusures. > > By the way we already have internal functions triggering warnings on > unknown arguments. This is also an unneeded inconsistency and more it's > invisible by the user without testing each function for it. > > At least simply ignoring passed arguments is a violation as described in > the following examples (http://3v4l.org/U2lnf): > > class Calculator { > public function calc($v) { > return $v + 1; > } > } > > class MyCalculator extends Calculator { > public function calc($v1, $v2 = 0) { > return parent::calc($v1) + $v2; > } > } > > function calcArray(array $values, Calculator $calculator) { > foreach ($values as &$v) { > $v = $calculator->calc($v, $v); // Second argument is wrong !! > } > return $values; > } > > $ar = [1,2,3]; > var_dump(calcArray($ar, new Calculator)); // ignores the second argument > var_dump(calcArray($ar, new MyCalculator)); // UNEXPECTED: the second > argument will be used > > > Both calculators should be 100% compatible but they aren't as the function > "calcArray" shows. > > > So because of the described issues with the existing code base I like to > propose the change to no longer ignore undefined arguments and introduce > E_DEPRECATED messages if a function get's an undefined argument. So the > user get enough time to fix their code before throwing errors in this case > in PHP 8. > > As this should be consistent over the engine I would propose this change > for user defined functions and for internal functions as well. > > Again, yes this one would introduces one more BC break but first this > would be deprecated before disabled and next it's for reducing BC in the > future. > > Marc > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > Have you checked https://wiki.php.net/rfc/strict_argcount? Only difference is that I'm proposing a warning instead of E_DEPRECATE, but it's still a draft and open to discussion. Maybe you would like to contribute to the RFC before it reaches discussion this week?
