Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125705
Content-Type: text/plain;
	charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Subject: Re: [PHP-DEV] Protected destructors
Date: Sat, 28 Sep 2024 13:50:27 -0400
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>
 <ab99755c-0773-48a5-8d90-94e4e74a0134@jnvsor.net>
To: php internals <internals@lists.php.net>
In-Reply-To: <ab99755c-0773-48a5-8d90-94e4e74a0134@jnvsor.net>
Message-ID: <ABA09F3F-91BD-49E6-B6D0-571517A54934@zort.net>
From: jbafford@zort.net (John Bafford)

On Sep 28, 2024, at 13:23, Jonathan Vollebregt <jnv@jnvsor.net> wrote:
>=20
>> Okay.  My point is that you cannot know (unless there are no circular
>> dependencies) *when* a destructor is called by the engine;
>=20
> The benefit of non-public visibility isn't when it's called, but how =
many times it's called. If you can declare your destructor non-public =
you can be confident it'll only be called once per instance (By the =
engine)
>=20
> Or is there a scenario where the engine will call a destructor more =
than once on the same instance?
>=20
>> Destructors should (IMHO) be public. Not necessarily because they can =
be called, but classes with destructors hint at underlying behavior 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.
>=20
> Wouldn't you have to read the code to see if it had a public =
destructor too?


I would argue that, semantically, destructors should be *private*. You =
should never need to know if a class has a destructor, and you should =
never call it manually. The engine should automatically handle calling =
parent destructors when necessary.

If there really is some logic in the destructor that a user of a class =
might legitimately want to use, then that should be exposed in a =
separate method (with a more appropriate name, and an implementation =
that handles that it might be called more than once) and have the =
destructor call that method.

-John=