Req #70906 [Opn->Wfx]: Error on string keyed array for call_user_func_array() et. al

From: Date: Fri, 13 Nov 2015 13:24:52 +0000
Subject: Req #70906 [Opn->Wfx]: Error on string keyed array for call_user_func_array() et. al
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-197236@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=70906&edit=1 ID: 70906 Updated by: nikic@php.net Reported by: chris dot wisefool at gmail dot com Summary: Error on string keyed array for call_user_func_array() et. al -Status: Open +Status: Wont fix Type: Feature/Change Request Package: *General Issues PHP Version: Irrelevant Block user comment: N Private report: N New Comment: The newer argument unpacking feature, which supersedes call_user_func_array and invokeArgs(), does error on string keys to ensure forward compatibility with named parameters. The old methods have been kept as is for reasons of backwards compatibility. Previous Comments: ------------------------------------------------------------------------ [2015-11-13 01:44:55] chris dot wisefool at gmail dot com Description: ------------ This is more a shot in the dark than an actual expected change, as I am sure PHP's devs are reluctant to change long-standing functionality that doesn't issue notices so that it does. Currently if you invoke call_user_func_array() or ReflectionMethod::invokeArgs with an array having string keys, it accepts the array, silently I guess calling array_values() on it. This, however, could easily fool beginners into thinking that it can map to the named parameters of the function (they should RTFM, but we all know a lot won't). If an error (even NOTICE) was thrown in this case, it would seem better. As an added benefit, if this was done, since calling call_user_func_array() et. al with an associative array would be effectively an error case, call_user_func_array could maybe later be extended to actually supply named parameters. Since I imagine a lot of framework code just passes to these functions, the framework users would for free get ability to provide named parameters too. That enhancement, however, is outside the scope of this ticket, of course. Test script: --------------- function doSomething($baz=null, $bar=null) {return compact('baz','bar')} call_user_func_array('doSomething', array('baz'=>3,'bar'=>5)); // case #1 - returns array('baz'=>3,'bar'=>5) call_user_func_array('doSomething', array('baz'=>3,'bar'=>5)); // case #2 - also returns array('baz'=>3,'bar'=>5) // thus, someone could easily think that: call_user_func_array('doSomething', array('bar'=>5,'baz'=>3)); // #case 3 - would also return array('baz'=>3,'bar'=>5) // but it doesn't, of course, instead returning array('baz'=>5,'bar'=>3) // I'm proposing that in case 2 & 3 that a NOTICE is generated: // Notice: Calling call_user_func_array() with string keys: interpreted as // indexed array. // or whatever better wording PHP dev's come up with ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=70906&edit=1

« previous php.bugs (#197236) next »