Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125702
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Sat, 28 Sep 2024 18:48:49 +0200
To: "Christoph M. Becker" <cmbecker69@gmx.de>,
 "Jonathan Vollebregt" <jnv@jnvsor.net>, internals@lists.php.net
Message-ID: <5813ec39-2cf9-4529-8069-8842d23fe8b6@app.fastmail.com>
In-Reply-To: <c3c32682-22ec-498c-a76d-83358208322f@gmx.de>
References: <e58b4566-25a7-4a33-8550-8dcb6052b784@jnvsor.net>
 <0a45288d-8ae1-4b1c-8836-6bdd1cf34eb2@gmx.de>
 <faadf801-1b56-41ee-94ee-377d79034bd1@jnvsor.net>
 <c3c32682-22ec-498c-a76d-83358208322f@gmx.de>
Subject: Re: [PHP-DEV] Protected destructors
Content-Type: multipart/alternative;
 boundary=b68211fa5666476f90bf63fafc5a0590
From: rob@bottled.codes ("Rob Landers")

--b68211fa5666476f90bf63fafc5a0590
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 28, 2024, at 16:46, Christoph M. Becker wrote:
> On 28.09.2024 at 16:21, Jonathan Vollebregt wrote:
>=20
> >> Hmm, I wonder about the use-cases of userland destructors.  It seem=
s to
> >> me they are mostly useful for sanity checks, and maybe to close
> >> resources.  Are there others?
> >>
> >> If not, I wouldn't worry much about the visibility of destructors,
> >> because resources are scheduled for replacement anyway.
> >
> > Besides closing resources and killing processes I've seen them store
> > data to disk for caching, remove temp files, call callbacks/dispatch
> > events, change state on other objects, dump stored errors to error_l=
og
> > in a loop in an error handler...
>=20
> Okay.  My point is that you cannot know (unless there are no circular
> dependencies) *when* a destructor is called by the engine; it may be
> called during some GC run, or during the request shutdown sequence.  As
> it's now, that happens pretty early during shutdown, but that *might*
> change when stream resources are converted to objects.  So you cannot =
be
> absolutely sure that everything works as expected in destructors.  This
> is a general issue for garbage collected languages; some of these have
> no destructors at all, for such reasons.

It=E2=80=99s undocumented, AFAIK, but the destructor behavior is pretty =
dependable atm. For example, local variables are almost always destructe=
d at the end of the current (function) scope. I am not sure what streams=
 have to do with GC, but I can=E2=80=99t see how streams would change th=
is behavior.

> > It looks like there's quite a lot of use-cases for them (Which can go
> > wrong if called twice) that don't necessarily require resources to be
> > involved
>=20
> Like I said, I wouldn't be particularly worried about clients calling a
> destructor manually (that's a bit different for the engine, since
> segfaultish conditions should be avoided).
>=20
> But I don't have a strong opinion about the visibility of destructors
> anyway.  I'm fine with allowing protected constructors.
>=20
> Christoph
>=20

Destructors should (IMHO) be public. Not necessarily because they can be=
 called, but classes with destructors hint at underlying behavior when d=
estructed. For performance, you might want to defer that by retaining a =
reference. If a class has a hidden destructor, you have to go read the c=
ode to find it.

That=E2=80=99s my 2=C2=A2

=E2=80=94 Rob
--b68211fa5666476f90bf63fafc5a0590
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title><style type=3D"text/css">p.Mso=
Normal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Sat, Sep 28,=
 2024, at 16:46, Christoph M. Becker wrote:<br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>On 28.09.2024 at 16:21, Jonathan Volleb=
regt wrote:<br></div><div><br></div><div>&gt;&gt; Hmm, I wonder about th=
e use-cases of userland destructors.&nbsp; It seems to<br></div><div>&gt=
;&gt; me they are mostly useful for sanity checks, and maybe to close<br=
></div><div>&gt;&gt; resources.&nbsp; Are there others?<br></div><div>&g=
t;&gt;<br></div><div>&gt;&gt; If not, I wouldn't worry much about the vi=
sibility of destructors,<br></div><div>&gt;&gt; because resources are sc=
heduled for replacement anyway.<br></div><div>&gt;<br></div><div>&gt; Be=
sides closing resources and killing processes I've seen them store<br></=
div><div>&gt; data to disk for caching, remove temp files, call callback=
s/dispatch<br></div><div>&gt; events, change state on other objects, dum=
p stored errors to error_log<br></div><div>&gt; in a loop in an error ha=
ndler...<br></div><div><br></div><div>Okay.&nbsp; My point is that you c=
annot know (unless there are no circular<br></div><div>dependencies) *wh=
en* a destructor is called by the engine; it may be<br></div><div>called=
 during some GC run, or during the request shutdown sequence.&nbsp; As<b=
r></div><div>it's now, that happens pretty early during shutdown, but th=
at *might*<br></div><div>change when stream resources are converted to o=
bjects.&nbsp; So you cannot be<br></div><div>absolutely sure that everyt=
hing works as expected in destructors.&nbsp; This<br></div><div>is a gen=
eral issue for garbage collected languages; some of these have<br></div>=
<div>no destructors at all, for such reasons.<br></div></blockquote><div=
><br></div><div>It=E2=80=99s undocumented, AFAIK, but the destructor beh=
avior is pretty dependable atm. For example, local variables are almost =
always destructed at the end of the current (function) scope. I am not s=
ure what streams have to do with GC, but I can=E2=80=99t see how streams=
 would change this behavior.<br></div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div>&gt; It looks like there's quite a lot =
of use-cases for them (Which can go<br></div><div>&gt; wrong if called t=
wice) that don't necessarily require resources to be<br></div><div>&gt; =
involved<br></div><div><br></div><div>Like I said, I wouldn't be particu=
larly worried about clients calling a<br></div><div>destructor manually =
(that's a bit different for the engine, since<br></div><div>segfaultish =
conditions should be avoided).<br></div><div><br></div><div>But I don't =
have a strong opinion about the visibility of destructors<br></div><div>=
anyway.&nbsp; I'm fine with allowing protected constructors.<br></div><d=
iv><br></div><div>Christoph<br></div><div><br></div></blockquote><div><b=
r></div><div>Destructors should (IMHO) be public. Not necessarily becaus=
e they can be called, but classes with destructors hint at underlying be=
havior when destructed. For performance, you might want to defer that by=
 retaining a reference. If a class has a hidden destructor, you have to =
go read the code to find it.<br></div><div><br></div><div>That=E2=80=99s=
 my 2=C2=A2</div><div><br></div><div id=3D"sig121229152">=E2=80=94 Rob<b=
r></div></body></html>
--b68211fa5666476f90bf63fafc5a0590--