Hi Marcio/internals, I just went through the RFC again (didn't check the discussion since our last chat about it in Room 11).
The section about '"Flexible" Interface Implementations' mentions the interface as an 'an acceptable “PHPism”'. This is not just an "acceptable PHPism", it's a "life saving PHPism". To give you an idea of the amount of code that was saved from a massive refactoring when ZF1 => ZF2 code was ported by current ZF2 users, think about all web apps that have form contextual validation. Guess what? Almost all web applications have forms, and almost all apps have something like a "confirm password" form. Yep, *ALL* ZF2 apps are affected by this RFC, and it will likely prevent an upgrade to PHP7 in the near future unless our users upgrade to ZF3, which will be PHP 5.5 based, and therefore without variadic arguments. This is not an interface that I'm proud of, but it is an interface that saved a lot of time/money to a lot of users, and that allows flexible handling of contextual validation where we didn't foresee one upfront (the interface is indeed *wrong*, but we can't fix it in a stable release). Until all of the framework and all of the users have migrated to variadic interfaces, this particular RFC is a problem. Getting this change into PHP7 would mean having a major part of the framework community having a real hard time in upgrading. Additionally to all these worries of mine, consider that mistakes like the one with the `ValidatorInterface` may happen again in the future, and this "PHPism" is actually saving our asses out there. Don't get rid of it for the sake of clean code, because these "dirty hacks" have already proven themselves REALLY useful. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 14 March 2015 at 00:37, Marcio Almada <marcio.w...@gmail.com> wrote: > Hi > > 2015-03-13 6:02 GMT-03:00 Patrick ALLAERT <patrickalla...@php.net>: > > > Le mer. 11 mars 2015 à 22:44, Marcio Almada <marcio.w...@gmail.com> a > > écrit : > > > >> 2015-03-11 6:27 GMT-03:00 Lester Caine <les...@lsces.co.uk>: > >> > >> > On 11/03/15 09:05, wp12173047-156224 wp12173047-156224 wrote: > >> > >> > Most of the examples being shown are examples of simple bad > programming > >> > practice that needs fixing anyway, and I would expect a proper code > >> > review to have picked them up, so don't see that adding the check in > PHP > >> > is essential. It would however be a useful addition but in the > E_STRICT > >> > category ... not that I want to maintain that, but being able to > ignore > >> > those errors until such time as it is appropriate to fix them. > >> > > > > I don't really see how this favors E_STRICT over E_NOTICE as any of this > > type of errors can be displayed/hidden independently. > > > > > >> I think this is a valid argument to keep the E_STRICT error level option > >> for the secondary voting. > >> That's a very useful information, thanks :) > >> > > > > It also depends on your perception of E_STRICT. This level has been > > introduced in 5.0 without being part of E_ALL in order to, among other > > things, avoid too much pain in the *** while migrating from 4.x to 5.x. > > As of 5.4, E_ALL contains E_STRICT and the difference between E_STRICT > and > > E_NOTICE/E_WARNING is certainly not in terms of severity. > > Using an undefined variable or property => notice. > > Trying to get property of non-object => notice. > > Use of undefined constant => notice > > > > For this reason, I think we should use the standard notice/warning/error > > levels as much as possible. You may take a look at Nikita's "Reclassify > > E_STRICT RFC" for more info about it. > > https://wiki.php.net/rfc/reclassify_e_strict > > > > Cheers, > > Patrick > > > > I talked to Nikita earlier today, in order to try to align the strict arg > count RFC with https://wiki.php.net/rfc/reclassify_e_strict and the > conclusion was the following: > > It's a good thing to reclassify E_STRICT as this simplifies PHP error model > and resolves the currently unclear role of strict standards notices. As a > supporter of Nikita's idea, I'm removing E_STRICT from the voting options. > Consider this my collaboration to help to unifiy the error level model and > go a bit farther from the current "error level buffet" state we got > ourselves historically, on PHP. > > This leaves us with E_WARNING vs E_NOTICE and I'm sufficiently comfortable > to allow a secondary voting between these two error levels. > > Thanks, > Márcio >
