On Tue, Apr 9, 2019 at 11:05 AM Gabriel O <gade...@gmail.com> wrote: >> On 9. Apr 2019, at 17:35, Levi Morrison <le...@php.net> wrote: >> >> If you want the reverse to be true, then your code has bugs waiting to >> show themselves. The earlier we can catch these bugs, the better. >> >> One thing to note is that return type information does permit >> optimizations in some cases. For instance, I believe if a private >> method has a return type constraint of int, then the optimizer can >> rule out certain edge cases, and in some cases use type specialized >> handlers. We can do these sorts of optimizations in more places if the >> LSP issues are always errors, instead of warnings. >> >> So for both correctness and performance, I support this change. > > >> If you want the reverse to be true, then your code has bugs waiting to >> show themselves > > I don’t, I just don’t want fatal errors in production when I upgrade > library I extend. Let me keep logging such issues and fix them later, > instead of producing hard crash for customers. > >> The earlier we can catch these bugs, the better. > > What prevents somebody to catch warnings? This RFC is about hard crash > that I disagree with. This type of issue is problematic only when > expecting parent but injecting child.
Have you considered testing your code in a dev environment after upgrading a library you extend, prior to pushing it to production? If you blindly push library updates to production without testing, there are many other types of errors you could run into besides this. I for one would welcome consistent fatal errors for LSP violations, to catch these kind of bugs as early as possible during development. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
