Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128381
Feedback-ID: id5114917:Fastmail
Date: Sun, 03 Aug 2025 11:06:09 +0100
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
User-Agent: K-9 Mail for Android
In-Reply-To: <f2753102-7d0d-4c06-995b-dc075f1c1900@app.fastmail.com>
References: <c24d84f3-0d9a-4412-8ea5-a87ebac2e64a@jnvsor.net> <2d516e15-2fc7-4ac4-b9c2-7146ac01cfb1@app.fastmail.com> <CAAwdEzCG-6Cfgiwa2g-c51_kz8VVMPcHN6pov7EWhE-rO2y=Ug@mail.gmail.com> <8c60c0b8-8826-49a4-80ba-973ff833fff7@app.fastmail.com> <CAAwdEzD_cA+c-wxovMEvnouLCY74NEhgCoaKJCCZP1_SiH+H-Q@mail.gmail.com> <900d2936-6afd-4eed-b08a-1540d124273a@app.fastmail.com> <43428CE0-2D9C-485C-969B-5529850614BE@rwec.co.uk> <86af366e-5a31-4f0b-9440-a1d052b97331@app.fastmail.com> <5C752175-C3ED-406C-B40A-84639358C24B@rwec.co.uk> <f2753102-7d0d-4c06-995b-dc075f1c1900@app.fastmail.com>
Message-ID: <559EE2D0-71FE-4321-B35E-A18468FEC364@rwec.co.uk>
Precedence: list
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

On 3 August 2025 10:30:13 BST, Rob Landers <rob@bottled=2Ecodes> wrote:
>I'm not sure that this is a bug=2E You can redeclare the same type and ad=
d hooks (or change them), which breaks all assumptions about substitutabili=
ty=2E

If substitutability was the problem, access to the re-declared property sh=
ould be forbidden to the parent class as well, but it's not: https://3v4l=
=2Eorg/OEadK

In fact, there's no break in the *contract* of the property there, only th=
e *implementation*, just like a method can be redefined to have completely =
different behaviour=2E

If anything, refusing access to a sibling class is a break in contact: in =
the original example, class C is written with the expectation that property=
 $v will be visible to it, for any instance of P it receives=2E

class P {
    protected $v =3D 1;
}
class C extends P {
    public function test(P $i) {
        return $i->v;
    }
}

This expectation holds, and appears to be a valid contract, regardless of =
whether the object given is an instance of P itself or of a subclass=2E=20

But, a completely unrelated class can create an object which satisfies ins=
tanceof P, but forbids access to property $v:

class C2 extends P {
    protected $v =3D 2;
}

Why should C2 have the right to break the expectation of C in that way?



Rowan Tommins
[IMSoP]