Hi Stas, > Stanislav Malyshev <smalys...@gmail.com> hat am 11. März 2015 um 05:49 > geschrieben: > > > Hi! > > > related to the proposed RFC. *But* after some heuristics it was > > noticeable that most warnings had a common cause. I parsed the output > > It doesn't matter if it has common cause or not. If I have a system of > Wordpress-like size, I'm bound to get a lot of failures, that's what it > is telling me. And 27 separate failures are non-negligible number.
This RFC doesn't add failures. It only makes failures visible. The failures are present without this this patch too but invisible. > > some code refactory that left function calls with residual parameters > > behind. This could be fixed in less than 1 hour. > > I think you are severely underestimating the cost of fixing it. Fixing > bugs is not only replacing the bytes. Same as above. The Bugs are there with and without this RFC. > > The ZF2 test suite couldn't run because of fatal errors caused by PHP7 > > incompatibilities > > or bugs that caused segfaults. Nothing related to the RFC itself. > > We do not know if something there is related to RFC or not. That's not > evidence that RFC is OK, that's evidence that a) we could not obtain the > information and b) we already have a BC problem so severe that we can > not run ZF2, and probably not easily fixable (since, I assume, if it > were easily fixable you'd have done so). That's why I am reluctant to > add more BC breaks, especially ones that bring no new capabilities but > just add more error messages. Each new BC break adds migration barriers, > and in my opinion, it's not even linear. The current fatals are not related to this patch. Sure, because of this it's unknown if there are other errors related to this patch but it doesn't make this RFC better or worse. In my opinion this RFC only introduces a very very small BC break and only in the case warnings are thrown as exceptions by the user (as in composer). This RFC only makes currently invisible failures visible. > > If compilation is "magic"... we are all magicians here. Calling the > > implementation "magic" > > won't change the fact that it's just a compilation check :D > > I didn't say compilation is "magic", you are strawmanning here. What I > said is that having different behavior of the compiler depending on > specific function calls made by the function being compiled is pretty > rare (not only in PHP but in other languages too) and non-obvious, and > thus suspicious. First of all please be consistent with your meaning ... on discussion about "$this from incompatible context" you liked to change a function callable or not if the function contains $this or not. In the normal case also say the function body should not define anything about how a function is callable but in this case the functions func_get_arg[s] already do this. > > BTW, the current PHP silent behavior should be considered even more > > confusing otherwise we > > wouldn't have these measurements: > > > > https://wiki.php.net/rfc/strict_argcount#bc_breaks_on_the_real_world > > I'm not sure how these prove current behavior is "confusing". Yes, there > are bugs in the code, and I'm sure this feature will expose some of > those (previously harmless) bugs. At cost of the BC break. And don't > think a handful of libraries represent the vast universe of PHP code, > most of which we can't even see because it's not published anywhere. What do you mean here? Again, introducing a warning isn't a real BC-break and as you says there are bugs it helps nobody ignoring them. If you think so you can do that with all of your own bugs by ignoring warnings/notices. > <snip> Marc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
