Bug #74394 [Com]: incosistent: Declaration of B::test(string $a) should be compatible

Edit report at https://bugs.php.net/bug.php?id=74394&edit=1 ID: 74394 Comment by: spam2 at rhsoft dot net Reported by: spam2 at rhsoft dot net Summary: incosistent: Declaration of B::test(string $a) should be compatible Status: Duplicate Type: Bug Package: *General Issues Operating System: Linux PHP Version: 7.1.4RC1 Block user comment: N Private report: N New Comment: > It appears to me that your actual problem is a very > broken management of project dependencies and/or deployments i doubt that after change 200000 lines of code which is deplyoed to currently over 200 websites to strict-types, type-hints and where possible return-types within a view months but what is NOT deployed is every single piece of customer specific code and for that cases it was no problem introduce type-hints, deploy to all websites, call autotest-suites and refliction-fuzzy-calls and just edit the extened classes within 30 minutes that is not possible with a stupid fatal error Previous Comments: ------------------------------------------------------------------------ [2017-04-09 00:14:52] nikic@php.net Of course it is possible to extend existing libraries with return types -- you just have to realize that, just like most changes to method signatures, this is a breaking change and must be versioned accordingly. Whether it results in a warning or a fatal error is irrelevant, it is a semver major change in any case. It appears to me that your actual problem is a very broken management of project dependencies and/or deployments -- I can hardly believe that I'm seeing a bug report in 2017 that is essentially based on "I do breaking code updates in production and then fix things based on warning logs". ------------------------------------------------------------------------ [2017-04-08 23:41:33] spam2 at rhsoft dot net so you are aware that it WILL NEVER be possible to extend existing libraries which are not defined as "final class" with return-types in PHP? > And a quick reminder: strict_types affects function *calls*, not declarations i know that - but i won't ever write any new script which does not start with <?php declare(strict_types=1); ------------------------------------------------------------------------ [2017-04-08 23:17:19] requinix@php.net No type implies it returns mixed so returning a string instead is allowed by LSP, and supporting overriding mixed was a necessary exception to the "return types are invariant" rule (which IIRC was mostly a technical limitation). And while some language changes in the past only introduced warnings for newly-invalid designs (like with case 1), using return types incorrectly is intentionally fatal and is a style I would expect to continue. If you want to know more, or at least more than I can remember given it's been three years, then you should check the RFC and read through the internals mailing list's archives to find its associated discussions. https://wiki.php.net/rfc http://news.php.net/php.internals (c. Mar 2014) or a third-party aggregator And a quick reminder: strict_types affects function *calls*, not declarations. ------------------------------------------------------------------------ [2017-04-08 22:15:31] spam2 at rhsoft dot net and by which logic can you add the return type to B::test() without any warning while in case of type-hints you get always warnings if there is the sligtest difference? and by which logic this needs to be FATAL ERROR instead just a warning? ------------------------------------------------------------------------ [2017-04-08 21:32:03] requinix@php.net Haven't you complained about this before? Your example allows B::test() to return anything. That conflicts with A::test's requirement that it returns a string. Similar problem with case 1 in fact. Having to deal with child classes when you want to alter a parent is a problem inherent to OOP as a whole. And before you mention polymorphism, return types are invariant for the time being. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=74394 -- Edit this bug report at https://bugs.php.net/bug.php?id=74394&edit=1