Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128380
Feedback-ID: ifab94697:Fastmail
Precedence: list
MIME-Version: 1.0
Date: Sun, 03 Aug 2025 11:30:13 +0200
To: internals@lists.php.net
Message-ID: <f2753102-7d0d-4c06-995b-dc075f1c1900@app.fastmail.com>
In-Reply-To: <5C752175-C3ED-406C-B40A-84639358C24B@rwec.co.uk>
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>
Subject: Re: [PHP-DEV] Protected inheritance hierarchies
Content-Type: multipart/alternative;
 boundary=422364facd704ef3a368340a7fe741dd
From: rob@bottled.codes ("Rob Landers")

--422364facd704ef3a368340a7fe741dd
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 3, 2025, at 11:10, Rowan Tommins [IMSoP] wrote:
> On 2 August 2025 21:59:20 BST, Rob Landers <rob@bottled.codes> wrote:
> >If this were the case, then creating a base class with default values=
 wouldn=E2=80=99t be possible. The memory exists and is set aside for th=
at.
>=20
> Sure it would: the default value is just an assignment that happens at=
 a particular point of the object's lifecycle. For a child class which o=
verrides the default of a parent (on a public or protected property), on=
ly the child class's assignment will ever be visible. So it would be per=
fectly valid for the class entry for the child class to only store that =
one assignment. I don't know if that actually happens; maybe the cost of=
 de-duplicating is not seen as worthwhile, and the assignments are just =
run in sequence every time.
>=20
> Regardless, the philosophical question in this thread seems to be whet=
her re-declaring a protected property should change the "ownership" of t=
hat property. I think it's natural that a protected property *only* decl=
ared in a sibling class can't be accessed, so some ownership needs to be=
 tracked.
>=20
> What seems surprising is that the ownership changes if the same proper=
ty is re-declared, especially since the new declaration has to match the=
 original (e.g. you can't change the type), and every possible access te=
lls the user the two declarations have been completely merged.=20
>=20
> Intuitively, an identical declaration with no change other than a defa=
ult value looks like it would be the same as overwriting the default in =
a constructor, but that is not the case. (https://3v4l.org/5iIak vs http=
s://3v4l.org/rL8pX)
>=20
> I'm inclined to agree that this is a bug, regardless of whether it's d=
ifficult to fix in the implementation.
>=20
>=20
> Rowan Tommins
> [IMSoP]
>=20

I'm not sure that this is a bug. You can redeclare the same type and add=
 hooks (or change them), which breaks all assumptions about substitutabi=
lity.

class A {
    protected int $v =3D 2;
}

class B extends A {
    public function getValue(A $v): void {
        echo $v->v;
    }
}

class C extends A {
    protected int $v { set =3D> $this->v * 2; }
}

$b =3D new B;
$c =3D new C;
$b->getValue($b);
$b->getValue($c);

C changes all assumptions from B's point of view (technically C is a vio=
lation of LSP from the perspective of A, thus it should not pretend to b=
e substitutable as A from the perspective of B when used in this way -- =
though other properties/methods may in fact be substitutable and be usef=
ul).

=E2=80=94 Rob
--422364facd704ef3a368340a7fe741dd
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Sun, Aug =
3, 2025, at 11:10, Rowan Tommins [IMSoP] wrote:</div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>On 2 August 2025 21:59:20 BST, Rob Land=
ers &lt;<a href=3D"mailto:rob@bottled.codes">rob@bottled.codes</a>&gt; w=
rote:</div><div>&gt;If this were the case, then creating a base class wi=
th default values wouldn=E2=80=99t be possible. The memory exists and is=
 set aside for that.</div><div><br></div><div>Sure it would: the default=
 value is just an assignment that happens at a particular point of the o=
bject's lifecycle. For a child class which overrides the default of a pa=
rent (on a public or protected property), only the child class's assignm=
ent will ever be visible. So it would be perfectly valid for the class e=
ntry for the child class to only store that one assignment. I don't know=
 if that actually happens; maybe the cost of de-duplicating is not seen =
as worthwhile, and the assignments are just run in sequence every time.<=
/div><div><br></div><div>Regardless, the philosophical question in this =
thread seems to be whether re-declaring a protected property should chan=
ge the "ownership" of that property. I think it's natural that a protect=
ed property *only* declared in a sibling class can't be accessed, so som=
e ownership needs to be tracked.</div><div><br></div><div>What seems sur=
prising is that the ownership changes if the same property is re-declare=
d, especially since the new declaration has to match the original (e.g. =
you can't change the type), and every possible access tells the user the=
 two declarations have been completely merged.&nbsp;</div><div><br></div=
><div>Intuitively, an identical declaration with no change other than a =
default value looks like it would be the same as overwriting the default=
 in a constructor, but that is not the case. (<a href=3D"https://3v4l.or=
g/5iIak">https://3v4l.org/5iIak</a> vs&nbsp;<a href=3D"https://3v4l.org/=
rL8pX">https://3v4l.org/rL8pX</a>)</div><div><br></div><div>I'm inclined=
 to agree that this is a bug, regardless of whether it's difficult to fi=
x in the implementation.</div><div><br></div><div><br></div><div>Rowan T=
ommins</div><div>[IMSoP]</div><div><br></div></blockquote><div><br></div=
><div>I'm not sure that this is a bug. You can redeclare the same type a=
nd add hooks (or change them), which breaks all assumptions about substi=
tutability.</div><div><br></div><div>class A {</div><div>&nbsp;&nbsp;&nb=
sp; protected int $v =3D 2;</div><div>}</div><div><br></div><div>class B=
 extends A {</div><div>&nbsp;&nbsp;&nbsp; public function getValue(A $v)=
: void {</div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; echo $v-&g=
t;v;</div><div>&nbsp;&nbsp;&nbsp; }</div><div>}</div><div><br></div><div=
>class C extends A {</div><div>&nbsp;&nbsp;&nbsp; protected int $v { set=
 =3D&gt; $this-&gt;v * 2; }</div><div>}</div><div><br></div><div>$b =3D =
new B;</div><div>$c =3D new C;</div><div>$b-&gt;getValue($b);</div><div>=
$b-&gt;getValue($c);</div><div><br></div><div>C changes all assumptions =
from B's point of view (technically C is a violation of LSP from the per=
spective of A, thus it should not pretend to be substitutable as A from =
the perspective of B when used in this way -- though other properties/me=
thods may in fact be substitutable and be useful).<br></div><div><br></d=
iv><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--422364facd704ef3a368340a7fe741dd--