Re: Parameter type widening RFC

Am 26.05.2017 um 18:10 schrieb Ryan Pallas:

On Fri, May 26, 2017 at 9:01 AM, lists@rhsoft.net <mailto:lists@rhsoft.net> <lists@rhsoft.net <mailto:lists@rhsoft.net>> wrote:

    Am 26.05.2017 um 16:26 schrieb Dan Ackroyd:

        On 26 May 2017 at 13:23, lists@rhsoft.net
        <mailto:lists@rhsoft.net> <lists@rhsoft.net
        <mailto:lists@rhsoft.net>> wrote:

            does that also fix the issue
            https://bugs.php.net/bug.php?id=74394
            <https://bugs.php.net/bug.php?id=74394>

        Dear Anonymous,

        That "issue" is actually 3 issues.

        case 1

        class A {
            public function test($a) {}
        }
        class B extends A {
            public function test(string $a) { }
        }

        This breaks LSP - because B::test doesn't accept all the things that
        A::test can accept and so is unlikely to ever be supported.

    and how is that a problem?

    A accepts anything
    B limits it's inut to a *subset* of "anything"

Because, if I have a function foo(A $a) { $a->test(new Bar()) } that I cannot pass B into this function, even though it is a subclass of A. You should be able to pass any subclass where its parent is expected, allowing parameter narrowing (covariance) would break this.

well, that case is at least a warning but add a return-type to the parent is a *fatal error* until you update the child class and that makes introducing return-types harder than it should be something like "covariance class {}" would be xtremely helpful for all that cases where you don't pass objects all day around but have them as a *library* in a singletone - in such cases there is no technical difference when you add a retrun-type to the parent class then before except that what was over years just a "@return integer" is now instead of a comment a language construct