On Wed, April 10, 2019 at 10:06 AM Gabriel O <gade...@gmail.com> wrote:
> On 10 April 2019 4:48:38 PM Theodore Brown <theodor...@outlook.com> wrote: > > > > I for one would welcome consistent fatal errors for LSP violations, > > to catch these kind of bugs as early as possible during development. > > Once again, nowadays warnings are converted to errors during development. > This change affects production only, where this isn't being done. > > > Have you considered testing > > I have yet to see codebase with 100% test coverage. Better idea is to use > static analyzer. My objection is for remaining cases. > > I don't understand what's the benefit of raising fatal error here. Code is > not lsp compliant? Cool, you will get hard error when calling such subclass > anyway. Until that call happens, there is no bug so warning is fine. > I have yet to see codebase with 100% test coverage. True, but I would think that after upgrading a library, one would at least do a basic test of loading the code that uses the library to see if it still works. > Until that call happens, there is no bug so warning is fine. I disagree. There is a bug, but without a fatal error at compile time you are less likely to find out about it until the relevant call happens. > I don't understand what's the benefit of raising fatal error here. Besides the benefit of finding bugs earlier, there is also the benefit of more performance optimization opportunities that Levi mentioned, as well as simplifying the PHP engine. [1] [1]: https://github.com/php/php-src/pull/4000 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
