[RFC][VOTE][RESTART] Strict Argument Count On Function Calls

There was no need to update the BC break section. The only minor change was
the addition of the following section:

Yeah, really strong -1 on this one, even after the modification.

Now that the RFC only covers static calling, all of the code it would
pickup could be easily found with a static code analysis tool. For
people who use those already, this RFC has zero benefits and only
downsides.

Having the behaviour of the language change depending on whether
func_get_args is in the body of the function is really pretty weird.
Similarly having the behaviour change based on how it's called is
nuts.

function foo() { ... }
$fn = 'foo';
$fn(1); //works
foo(1); //breaks;

If this RFC does pass, it will be an instant addition to phpsadness.com.

Also, the RFC talks a lot about BC breaks but it doesn't even consider
Forward Compatibility. Imagine I have a library that other people use
with a function foo($x) {}

I can add other parameters to that function without breaking any code
by using a parameter with a default value i.e. function foo($x, $y = null) {}

Currently, I can also remove the parameter to make the function
signature be function foo($x) {} without anything breaking.

This means that people can run their code both against the current
version of the library and the next one, which allows them to test a
new version of a library without having to modify their code, so are
still able to run the current version.

As Marco said, even if it's possible to 'fix' the code that uses this
behaviour - it's a really really useful pattern in the rare case where
it's needed.

cheers
Dan

Zitat von Marcio Almada marcio.web2@gmail.com:

Hi,

As promised, the "Strict Argument Count" RFC vote was restarted:

RFC: https://wiki.php.net/rfc/strict_argcount
PR: https://github.com/php/php-src/pull/1108

There was no need to update the BC break section. The only minor change was
the addition of the following section:

https://wiki.php.net/rfc/strict_argcount#about_callbacks_invoke_and_dynamic_calls

The voting will close in exactly 14 days counting from now. This is the
discussion summary so far http://markmail.org/thread/ol5s2vhw35ac2px3

Acknowledgments to Bob Weinand for offering a practical solution that will
help many in case the RFC passes.

Thanks,
Márcio

I voted no because I see the "Flexible" Interface Implementations
mentioned in the RFC a valid and common use case, and the proposed
solutions not suitable.

You probably haven't found those during real code tests because it's
commonly used to "migrate" or "extend" APIs. You add a new optional
parameter to both the caller and callee of an API, with defensive
coding so that both still work if that parameter is not available.
This is done to not require new dependency versions. But you won't
find those cases if you test complete software stacks, because in the
most current version of both modules you will have the new parameter
available.
Beside that, your testing sample was pretty small.

Jan.

--
Jan Schneider
The Horde Project
http://www.horde.org/
https://www.facebook.com/hordeproject