Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123980
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [RFC] Static class
In-Reply-To: <554ffb9e-35c5-466e-aace-0501eee3d0bd@bastelstu.be>
Date: Thu, 27 Jun 2024 20:43:40 -0400
Cc: Bilge <bilge@scriptfusion.com>,
 php internals <internals@lists.php.net>,
 lnearwaju@gmail.com
Content-Transfer-Encoding: quoted-printable
Message-ID: <6452BECC-BB20-48DC-9595-324EA70E6A67@newclarity.net>
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <CANLbj-qvn-BFfN8hEQRciUuT_qCiiPfyqc=YiL1Pw5+Oy-Ad4Q@mail.gmail.com>
 <554ffb9e-35c5-466e-aace-0501eee3d0bd@bastelstu.be>
To: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
From: mike@newclarity.net (Mike Schinkel)

> On Jun 27, 2024, at 2:11 PM, Tim D=C3=BCsterhus <tim@bastelstu.be> =
wrote:
> Marking a class as 'static' *does* affect how the class may be used =
and thus the static-ness is part of the public API. Therefore it should =
be a keyword. Everything else would also be inconsistent with final =
classes effectively making all members final and readonly classes making =
all members readonly.

Very insightful; that is a great rule of thumb.

>> I also believe that static classes should be implictly final. Given =
that no objects of such a class can exist, they cannot be exchanged by a =
different class anyways=20

I object here.=20

There are functions in classes that I have built in the past that are =
static and also benefit from inheritance.  Could they be called directly =
on the base class; yes?  But that is less elegant and increases =
complexity with two levels of inheritance are needed. =20

Specifically the functionality I am thinking of is the base class is =
generic functionality for factory functions and then child factory =
functions implement use-case specific logic for the type of the object =
produced. For example, each of these functions has a MakeNew(...) =
function, and children call self::MakeNew(...).

Base
-- Term
-- User
-- BasePost
    -- Post
    -- Page

That is a subset of classes I used, and those classes were designed for =
use with WordPress.=20

Further, these classes implemented "hooks" in WordPress. Using =
inheritance allowed all the hooks to be managed without repeating them =
in many places, being able to modify them for a class-specific need, and =
also without accidentally forgetting to add them.

>> and inheritance is not meant for code reuse.

Just because code reuse in inheritance can be problematic it does not =
have to be in all-cases. Moderation in all things. I used that approach =
for 10+ years and never once had any of the problems people claim about =
using inheritance for code reuse. This was likely because my needs were =
constrained by the use-case and by nature did not grow out of control =
with complexity.

So I would really hate to finally get static classes but still not be =
able to use them as intended for select use-cases only because someone =
decided without knowing all applicable use-cases that they did not like =
the idea of people using inheritance.

-Mike