On 16 March 2015 at 02:31, Marcio Almada <marcio.w...@gmail.com> wrote:
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
