Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121755
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.200.91.1.1\))
Date: Wed, 22 Nov 2023 14:29:35 +0100
References: <79d675e3-95b4-40bb-baf4-3e1c998f5390@online-presence.ca>
 <B6359F06-6864-4DE8-84CE-2558520E3B18@gmail.com>
 <ad169242-e52e-42d1-aa0d-c4d36cc566da@app.fastmail.com>
 <d08dffeb-3503-4d60-8451-b1ce5f812549@online-presence.ca>
To: php internals <internals@lists.php.net>
In-Reply-To: <d08dffeb-3503-4d60-8451-b1ce5f812549@online-presence.ca>
Message-ID: <99D672A1-7D00-49CF-B49B-90081881DB1F@cschneid.com>
Subject: Re: [PHP-DEV] RFC Proposal - static modifier for classes
From: cschneid@cschneid.com (Christian Schneider)

Am 20.11.2023 um 22:00 schrieb Lanre Waju <lanre@online-presence.ca>:
> I will have to disagree with everything you said:

Side-note: This is IMHO not a good intro into a discussion ;-)

> I outlined what a static class would be: A class that cannot be =
instantiated in which all members are implicitly static. We already have =
static members, so please elaborate on the maintenance burden that =
adding static to a class as that could help explain better, i mean what =
feature doesn't have technical debt associated with it? The new JIT =
engine?

That is his point: The benefit has to outweigh the debt and for =
something like a class modifier this can lead to a matrix of possible =
combinations, complication things down the line.

>>> 3. It is entirely opt-in. If you hold reservations about using =
static
>>> classes, you can simply choose not to use them.
>> This is a spurious and disingenuous argument, even if it gets trotted =
out frequently on many RFCs.  I'm not picking on you in particular here, =
but it's a bad argument to use, period, 99% of the time, no matter who =
is saying it.
> If you insist, Mr. Larry.

I=E2=80=99m with Larry there: Being able to just ignore new features is =
sometimes helpful (i.e. avoids the discussion about BC) but not a strong =
argument on *why* something should be added. This lists very much also =
cares about the implementation and maintenance costs as well as the =
simplicity/consistency of PHP. Being opt-in just does not carry much =
weight in that context.

>> Similarly, if we add a static marker to classes, that means all =
future improvements to classes need to consider "but what if the class =
is static?"  Eg, there was discussion a while back about `data` classes. =
 What happens if you have a `static data class`?  Is that a syntax =
error?  Does it work?  If it works, what does "work" mean?  What about =
sealed classes?  Can you have a sealed static class?  What would that =
mean?  Those are questions that would need to be answered, because this =
feature exists.
> Either i'm in an alternate reality where the data classes and sealed =
classes rfcs passed, or I've just been straw-manned. Either way, is it =
really that difficult to decide on as a community what a static data =
class implies? We have already established that a static class means all =
the members are static, but i can try to dumb it down for you if need =
be.

Being a long time member of this list (even though with only very =
occasional contributions to the source code) I have to say: There is a =
wide range of experience in both language design and implementation (for =
both PHP and in general) represented here, some members coming from an =
almost exclusively language-user point of view. And that is a great =
thing!
But I=E2=80=99d recommend to not underestimate the knowledge contributed =
by people who have been involved for some time and possibly even learned =
from previous mistakes :-)

Having said all that I just wanted to add that I would most probably =
vote against static classes even though we use class-as-a-namespace here =
sometimes but still don=E2=80=99t feel the need for it to being a =
language feature for the reasons mentioned by Rowan and Larry.

Regards,
- Chris