Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123791
Precedence: bulk
MIME-Version: 1.0
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com> <501a6892-377b-4156-a18e-a9b3eb33d629@scriptfusion.com>
In-Reply-To: <501a6892-377b-4156-a18e-a9b3eb33d629@scriptfusion.com>
Date: Mon, 24 Jun 2024 23:17:10 +0200
Message-ID: <CAPzBOBNxCQzdjq9udQ9DzEEA=r4Qn1g-4m90Gqj1ZGQDpqAf0w@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Static class
To: Bilge <bilge@scriptfusion.com>
Cc: Claude Pache <claude.pache@gmail.com>, php internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Mon, Jun 24, 2024 at 10:22=E2=80=AFPM Bilge <bilge@scriptfusion.com> wro=
te:
>
> On 24/06/2024 09:27, Claude Pache wrote:
>
> Hi,
>
> Hi Claude! I really appreciate your feedback. Everything you highlighted =
is an important point that will be included in the RFC!
>
> A general remark: I appreciate that a static class does not impose arbitr=
ary restrictions (like: implicitly `final`) on the class beyond what is mea=
ningful for staticness. On the other side, I don=E2=80=99t think that we sh=
ould support markers that are technically possible, but semantically meanin=
gless, like the `readonly` marker on class.
>
> Great point, `readonly` and `static` should be mutually exclusive and gen=
erate a compile-time error, since `readonly static` properties are not supp=
orted.
>
> Some more specific remarks:
>
> * In the intro: =E2=80=9CA static class is a class whose members (propert=
ies and methods) are all static=E2=80=9D. One of the most important point i=
s missing, namely: It is meaningless for a static class to have instances.
>
> I thought that was covered off, but I'll see if I can word it better.
>
> * In the =E2=80=9CProposal=E2=80=9D section, it should be stated explicit=
ly that any attempt to construct an instance, not only with `new`, but also=
 with any of the `ReflectionClass::newInstance*()` methods, or with `unseri=
alize()`, or with whatever other mean, shall fail.
>
> Great point, I'll include that detail. I think we're also missing a simil=
ar detail with respect to dynamic properties, which should of course also b=
e forbidden.
>
> Should a static class be marked `readonly` or `abstract`? I think not, be=
cause those have no real semantic meaning for static class; their effects o=
n static members are only consequences of their intended meaning on non-sta=
tic class:
>
> * Unless/until the `readonly` marker may be applied to static properties,=
 the only effect of such a keyword, is that it would prevent the creation o=
f static properties. I don=E2=80=99t know if that restriction is useful, bu=
t in case it would be used for that purpose, it would be hijacking the `rea=
donly` marker for a something it wasn=E2=80=99t intended for.
>
> Agree, as above, we'll make them mutually exclusive.
>
> * The main purpose of the `abstract` keyword is to prevent a class to be =
instantiated, which (in case of static class) is more semantically describe=
d by the `static` marker. Beyond that, it just allows to declare a method t=
hat, if implemented by a subclass, should have a compatible signature. Most=
 notably, it does not prevent the other static members of the class to be u=
sed directly.
>
> I tend to find inheritance is not a very useful concept in static context=
s, but others have already pointed out that some have found uses for it. Du=
e to my lack of experience I cannot confidently say that `abstract static` =
has no value, but you make a compelling argument. Happy to add a similar mu=
tual exclusivity prohibition for this keyword too, unless and until someone=
 protests it with an equally compelling argument to the contrary.
>
> The RFC says that a static class may extend a class not explicitly marked=
 as static, but with no instance member. This is not sound, because a class=
 with no instance members is not necessarily static. The most obvious examp=
le is `stdClass` (which has no member at all, even if their instances may h=
ave properties).
>
> Do you mean it is not simply sufficient for a class to be regarded as imp=
licitly static by virtue of the fact that it has no instance members? I'm n=
ot sure I agree, but I may be missing something. If we extend `stdClass` th=
en we gain nothing, and our class so extending it can still be safely marke=
d static, can it not? Please elaborate so I might understand better.
>
> Kind regards,
> Bilge

Hey Bilge,

> Do you mean it is not simply sufficient for a class to be regarded as imp=
licitly static by virtue of the fact that it has no instance members? I'm n=
ot sure I agree, but I may be missing something. If we extend `stdClass` th=
en we gain nothing, and our class so extending it can still be safely marke=
d static, can it not? Please elaborate so I might understand better.

I think it is sound in theory, but in practice, it will be a foot gun.
Imagine if you were to take my HTTP code library and make something
static from it. Later, I added an instance member. Now, when you
upgrade, everything starts crashing because of one little change
unrelated to your code.