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: > No type implies it returns mixed so returning a string > instead is allowed by LSP and how is it then a problem when the parent class only returns a string which is a subset of "mixed" of the extedning class? _______________________- maybe you guys also don't see the possibility of shared-libraries used by hundrets of applications by just use "include_path" when you talk about "deplyoment" and "2017" - catch every extending consumer is a hard task in that context and there is *no reason* using common sense because when the extending class has no return-type and so allows anything how is it a problem when parent::method() only returns a defined type which is a *subset* of what the extending class allows to return? Previous Comments: ------------------------------------------------------------------------ [2017-04-09 00:59:12] spam2 at rhsoft dot net and to "broken management of project dependencies and/or deployments" - believe it or not - that 200.000 LOC are a one-man-show maintained since 2013 and even the first project is running as fine as 14 years before - not everybody needs to hang his life on ansible & friends when he developed his own deployment tools (in PHP) long before all the "hot stuff" existed and that is all perfectly maintainable and controllable until someone introduces fatal errors for no good reasons ------------------------------------------------------------------------ [2017-04-09 00:53:48] spam2 at rhsoft dot net > 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 ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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