Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123627
Feedback-ID: ifab94697:Fastmail
User-Agent: Cyrus-JMAP/3.11.0-alpha0-515-g87b2bad5a-fm-20240604.001-g87b2bad5
Precedence: bulk
MIME-Version: 1.0
Message-ID: <506f21b6-6aff-41c7-930e-4621885ed724@app.fastmail.com>
In-Reply-To: <04ae10a2-ceae-4996-a7fe-9b38d2f81ca2@scriptfusion.com>
References: <0cf69a14-f1b5-4077-9d91-d7b579485eec@scriptfusion.com>
 <936e1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk>
 <04ae10a2-ceae-4996-a7fe-9b38d2f81ca2@scriptfusion.com>
Date: Sun, 16 Jun 2024 11:49:49 +0200
To: internals@lists.php.net
Subject: Re: [PHP-DEV] Static class
Content-Type: multipart/alternative;
 boundary=61747049af8249f999eae94cd5f266fb
From: rob@bottled.codes ("Rob Landers")

--61747049af8249f999eae94cd5f266fb
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable



On Sun, Jun 16, 2024, at 11:17, Bilge wrote:
> Let's start getting specific so we can make some progress.
>=20
> The goals of this RFC are fairly straightforward:
>  =E2=80=A2 Introduce the `static` keyword at the class level to preclu=
de the need to create a private constructor. That is, `__construct` woul=
d be invalid in a static class.
>  =E2=80=A2 Prohibit instantiation of a static class with a language-le=
vel error.
>  =E2=80=A2 Prohibit declaration of instance members in a static class =
with a language-level error.
> However, as ever, there's a devil in the details. In particular, we ne=
ed to consider the following:
>=20
>=20
>   1. Since a "static class" implies all members are static, should we =
still allow explicit static method declarations with the `static` keywor=
d?
>=20

To keep it inline with readonly and abstract. I would look to those and =
follow their rules.=20

>=20
>   2. Should `static` imply `final`?
>     2a. If yes, should `final` still be allowed to be explicitly decla=
red, despite being implied?
>=20

I would allow it, though emit a warning that it=E2=80=99s unnecessary. T=
hat=E2=80=99s what I would expect from a compiled language, anyway.=20

>=20
>   3. Should a "static class" prohibit inheritance?
>=20

I would think it should be allowed. This is one of the most annoying thi=
ngs about static classes in C#. That being said, PHP has traits, so stat=
ic classes could theoretically use traits to provide inheritance-like be=
havior. Can traits be marked static, or just classes?

>=20
>   4. Should a "static class" permit state?
>=20

Here=E2=80=99s the thing, there are still ways to get state even if you =
disallow it (create a function called getState() that has an internal st=
atic array). Using state in a static class is a code smell, for sure. Ho=
wever, constants should be allowed and even those are quite limited in w=
hat values they can hold. Until that gets cleared up, we should perhaps =
allow variables so complex constants can exist (implementing the constru=
ction of them, however, should be left as an exercise for the developer).

>=20
>   5. Should traits be permitted in a static class?
>=20

I hope so. Traits are some of the most abused super powers of PHP.=20

>=20
>   6. Which magic methods (if any) should be valid in a static class?
>=20

Are magic methods allowed in a static context? If so, only those should =
be implementable.=20

> Based on my current understanding, I would propose the following answe=
rs to these questions:
>=20
>=20
>   1. In order to make upgrading simple and keep method intentions clea=
r, `static` should not only be valid but also required on each method de=
claration, as usual for static methods.
>   2. Inheritance doesn't make much sense in a purely static context, d=
espite the fact that PHP has a static resolution operator; I often find =
this is an anti-pattern. In any case, this is a non-BC issue if we lock =
down inheritance for now and later decide to open it up. Disabling inher=
itance also is in-line with the C# implementation of the same.
>     2a. Since under this proposal, `final` is implied, it should not b=
e necessary (or allowed) to be specified. Upgrading would be simply a ca=
se of replacing `final` with `static` in-place.
>   3. As already mentioned, inheritance in a purely static context does=
n't make much sense, and it's a non-BC break to prohibit it and later en=
able it. This decision is also in-line with the C# implementation.
>   4. Perhaps the most contentious decision, we could disable state and=
 later enable it if there is a need, without BC. I personally cannot thi=
nk of a time when I needed state in a static class. That said, I do not =
agree with disabling state within the language. In case someone is relyi=
ng on static state in such a class, upgrading would be impossible; they =
would instead have to avoid marking the class as static, which defeats t=
he purpose of this RFC. I believe we should support state, and if someon=
e dislikes static state, they should enforce that with a code style rule=
 in their project; this is not something that should be prohibited by th=
e language itself as "regular" classes already allow this.
>   5. Provided a trait follows the rules of the static class (i.e. all =
members are static), it seems to me this should be allowed, though I hav=
e little use for it myself.
>   6. Given there are many magic methods, this topic probably deserves =
a separate discussion; it is not something I have spent a lot of time on=
 thus far so it is just included for visibility at this time.
>=20
> If there are any strongly dissenting opinions on any of these points, =
or any significant points I may have missed, please share. Otherwise, I =
would be happy to draw up and RFC along these lines (notwithstanding I h=
ave no RFC karma at present), followed by an implementation once all out=
standing questions are answered.
>=20
>=20
> Cheers,
> Bilge
>=20
>=20
> On 15/06/2024 14:53, Rowan Tommins [IMSoP] wrote:
>> On 15/06/2024 12:16, Bilge wrote:
>>>=20
>>> I want to introduce the `static` keyword at the class declaration le=
vel. That is, the following would be valid: `static class Foo {}`.
>>=20
>>=20
>> This has been proposed before, and was rejected at vote. It was nearl=
y 10 years ago, so opinions may have changed, but it would be worth read=
ing through the prior discussion to anticipate or counter the objections=
 raised, and avoid re-treading the same ground.=20
>>=20
>> - RFC: https://wiki.php.net/rfc/abstract_final_class=20
>> - Pre-vote discussion threads: https://externals.io/message/79211 and=
 https://externals.io/message/79338=20
>> - Final vote thread: https://externals.io/message/79601=20
>>=20
>> Searching my list archive, I find that it came up again a few months =
ago, which I'd entirely forgotten: https://externals.io/message/121717=20
>>=20
>> Slightly tangential, but some of the same discussion also came up on =
these rather lengthy threads about "static class constructors": https://=
externals.io/message/84602 and https://externals.io/message/85779=20
>>=20
>>=20
>> Regards,
>=20
>=20

=E2=80=94 Rob
--61747049af8249f999eae94cd5f266fb
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><br></div><div>=
<br></div><div>On Sun, Jun 16, 2024, at 11:17, Bilge wrote:<br></div><bl=
ockquote type=3D"cite" id=3D"qt" style=3D""><div class=3D"qt-moz-cite-pr=
efix">Let's start getting specific so we can
      make some progress.<br></div><div class=3D"qt-moz-cite-prefix"><br=
></div><div class=3D"qt-moz-cite-prefix">The goals of this RFC are fairly
      straightforward:<br></div><div class=3D"qt-moz-cite-prefix"><ul><l=
i>Introduce the `static` keyword at the class level to
          preclude the need to create a private constructor. That is,
          `__construct` would be invalid in a static class.<br></li><li>=
Prohibit instantiation of a static class with a
          language-level error.<br></li><li>Prohibit declaration of inst=
ance members in a static class
          with a language-level error.<br></li></ul><p>However, as ever,=
 there's a devil in the details. In
        particular, we need to consider the following:<br></p><p></p><di=
v>&nbsp; 1. Since a "static class" implies all members are static,
        should we still allow explicit static method declarations with
        the `static` keyword?<br></div><p></p></div></blockquote><div><b=
r></div><div>To keep it inline with readonly and abstract. I would look =
to those and follow their rules.&nbsp;</div><div><br></div><blockquote t=
ype=3D"cite" id=3D"qt" style=3D""><div class=3D"qt-moz-cite-prefix"><p><=
/p><div> &nbsp; 2. Should `static` imply `final`?<br></div><div> &nbsp;&=
nbsp;&nbsp; 2a. If yes, should `final` still be allowed to be explicitly
        declared, despite being implied?<br></div><p></p></div></blockqu=
ote><div><br></div><div>I would allow it, though emit a warning that it=E2=
=80=99s unnecessary. That=E2=80=99s what I would expect from a compiled =
language, anyway.&nbsp;</div><div><br></div><blockquote type=3D"cite" id=
=3D"qt" style=3D""><div class=3D"qt-moz-cite-prefix"><p></p><div> &nbsp;=
 3. Should a "static class" prohibit inheritance?<br></div><p></p></div>=
</blockquote><div><br></div><div>I would think it should be allowed. Thi=
s is one of the most annoying things about static classes in C#. That be=
ing said, PHP has traits, so static classes could theoretically use trai=
ts to provide inheritance-like behavior. Can traits be marked static, or=
 just classes?</div><div><br></div><blockquote type=3D"cite" id=3D"qt" s=
tyle=3D""><div class=3D"qt-moz-cite-prefix"><p></p><div> &nbsp; 4. Shoul=
d a "static class" permit state?<br></div><p></p></div></blockquote><div=
><br></div><div>Here=E2=80=99s the thing, there are still ways to get st=
ate even if you disallow it (create a function called getState() that ha=
s an internal static array). Using state in a static class is a code sme=
ll, for sure. However, constants should be allowed and even those are qu=
ite limited in what values they can hold. Until that gets cleared up, we=
 should perhaps allow variables so complex constants can exist (implemen=
ting the construction of them, however, should be left as an exercise fo=
r the developer).<br></div><div><br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div class=3D"qt-moz-cite-prefix"><p></p><div> &nbsp; 5.=
 Should traits be permitted in a static class?<br></div><p></p></div></b=
lockquote><div><br></div><div>I hope so. Traits are some of the most abu=
sed super powers of PHP.&nbsp;<br></div><div><br></div><blockquote type=3D=
"cite" id=3D"qt" style=3D""><div class=3D"qt-moz-cite-prefix"><p></p><di=
v> &nbsp; 6. Which magic methods (if any) should be valid in a static
        class?<br></div><p></p></div></blockquote><div><br></div><div>Ar=
e magic methods allowed in a static context? If so, only those should be=
 implementable.&nbsp;</div><div><br></div><blockquote type=3D"cite" id=3D=
"qt" style=3D""><div class=3D"qt-moz-cite-prefix"><p>Based on my current=
 understanding, I would propose the
        following answers to these questions:<br></p><p></p><div>&nbsp; =
1. In order to make upgrading simple and keep method
        intentions clear, `static` should not only be valid but also
        required on each method declaration, as usual for static
        methods.<br></div><div> &nbsp; 2. Inheritance doesn't make much =
sense in a purely static
        context, despite the fact that PHP has a static resolution
        operator; I often find this is an anti-pattern. In any case,
        this is a non-BC issue if we lock down inheritance for now and
        later decide to open it up. Disabling inheritance also is
        in-line with the C# implementation of the same.<br></div><div> &=
nbsp;&nbsp;&nbsp; 2a. Since under this proposal, `final` is implied, it =
should
        not be necessary (or allowed) to be specified. Upgrading would
        be simply a case of replacing `final` with `static` in-place.<br=
></div><div> &nbsp; 3. As already mentioned, inheritance in a purely sta=
tic
        context doesn't make much sense, and it's a non-BC break to
        prohibit it and later enable it. This decision is also in-line
        with the C# implementation.<br></div><div> &nbsp; 4. Perhaps the=
 most contentious decision, we could disable
        state and later enable it if there is a need, without BC. I
        personally cannot think of a time when I needed state in a
        static class. That said, I do not agree with disabling state
        within the language. In case someone is relying on static state
        in such a class, upgrading would be impossible; they would
        instead have to avoid marking the class as static, which defeats
        the purpose of this RFC. I believe we should support state, and
        if someone dislikes static state, they should enforce that with
        a code style rule in their project; this is not something that
        should be prohibited by the language itself as "regular" classes
        already allow this.<br></div><div> &nbsp; 5. Provided a trait fo=
llows the rules of the static class
        (i.e. all members are static), it seems to me this should be
        allowed, though I have little use for it myself.<br></div><div> =
&nbsp; 6. Given there are many magic methods, this topic probably
        deserves a separate discussion; it is not something I have spent
        a lot of time on thus far so it is just included for visibility
        at this time.<br></div><p></p><p>If there are any strongly disse=
nting opinions on any of these
        points, or any significant points I may have missed, please
        share. Otherwise, I would be happy to draw up and RFC along
        these lines (notwithstanding I have no RFC karma at present),
        followed by an implementation once all outstanding questions are
        answered.<br></p><p></p><div>Cheers,<br></div><div> Bilge<br></d=
iv><p></p></div><div class=3D"qt-moz-cite-prefix"><br></div><div class=3D=
"qt-moz-cite-prefix">On 15/06/2024 14:53, Rowan Tommins
      [IMSoP] wrote:<br></div><blockquote type=3D"cite" cite=3D"mid:936e=
1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk"><div>On
      15/06/2024 12:16, Bilge wrote:<br></div><blockquote type=3D"cite">=
<div><br></div><div>I want to introduce the `static` keyword at the class
        declaration level. That is, the following would be valid:
        `static class Foo {}`.<br></div></blockquote><div><br></div><div=
><br></div><div>This has been proposed before, and was rejected at vote.=
 It was
      nearly 10 years ago, so opinions may have changed, but it would be
      worth reading through the prior discussion to anticipate or
      counter the objections raised, and avoid re-treading the same
      ground. <br></div><div> <br></div><div> - RFC: <a class=3D"qt-moz-=
txt-link-freetext" href=3D"https://wiki.php.net/rfc/abstract_final_class=
">https://wiki.php.net/rfc/abstract_final_class</a> <br></div><div> - Pr=
e-vote discussion threads: <a class=3D"qt-moz-txt-link-freetext" href=3D=
"https://externals.io/message/79211">https://externals.io/message/79211<=
/a> and <a class=3D"qt-moz-txt-link-freetext" href=3D"https://externals.=
io/message/79338">https://externals.io/message/79338</a> <br></div><div>=
 - Final vote thread: <a class=3D"qt-moz-txt-link-freetext" href=3D"http=
s://externals.io/message/79601">https://externals.io/message/79601</a> <=
br></div><div> <br></div><div> Searching my list archive, I find that it=
 came up again a few
      months ago, which I'd entirely forgotten: <a class=3D"qt-moz-txt-l=
ink-freetext" href=3D"https://externals.io/message/121717">https://exter=
nals.io/message/121717</a> <br></div><div> <br></div><div> Slightly tang=
ential, but some of the same discussion also came up
      on these rather lengthy threads about "static class constructors":=
 <a class=3D"qt-moz-txt-link-freetext" href=3D"https://externals.io/mess=
age/84602">https://externals.io/message/84602</a> and <a class=3D"qt-moz=
-txt-link-freetext" href=3D"https://externals.io/message/85779">https://=
externals.io/message/85779</a> <br></div><div> <br></div><div> <br></div=
><div> Regards,<br></div></blockquote><p><br></p></blockquote><div><br><=
/div><div id=3D"sig121229152">=E2=80=94 Rob<br></div></body></html>
--61747049af8249f999eae94cd5f266fb--