> Le 24 juin 2024 à 01:10, Bilge <[email protected]> a écrit :
>
> Hi Internals!
>
> I am pleased to present my first RFC: Static class <https://wiki.php.net/rfc/static_class>.
>
> This work is based on the previous discussion thread on this list of the same name, and
> hopefully captured all the relevant details, notwithstanding anything unanticipated that may present
> itself during the implementation. Let me know if you feel anything important has been missed. I am
> aware it omits to mention specifics about messages so emitted when runtime or compile-time errors
> occur, but I anticipate this can be hashed out in the PR, unless consensus indicates otherwise.
>
> I am aware this idea is not supported by everyone, but there seemed to be enough positive
> voices for it to be worth a shot. I'd like to get a better idea of where people might stand
> when it comes down to a vote, now there is a formal RFC, so we know whether it's worth
> completing the implementation, although any sentiments so proffered are of course not a commitment
> to vote any particular way and nobody should feel compelled to speak to that unless comfortable.
> Looking forward to feedback!
>
> Cheers,
> Bilge
Hi,
A general remark: I appreciate that a static class does not impose arbitrary restrictions (like:
implicitly final) on the class beyond what is meaningful for staticness. On the other
side, I don’t think that we should support markers that are technically possible, but semantically
meaningless, like the readonly marker on class.
-----
Some more specific remarks:
* In the intro: “A static class is a class whose members (properties and methods) are all
static”. One of the most important point is missing, namely: It is meaningless for a static class
to have instances.
* In the “Proposal” section, it should be stated explicitly that any attempt to construct an
instance, not only with new, but also with any of the
ReflectionClass::newInstance*() methods, or with unserialize(), or with
whatever other mean, shall fail.
-----
Should a static class be marked readonly or abstract? I think not, because
those have no real semantic meaning for static class; their effects on static members are only
consequences of their intended meaning on non-static 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 of static properties. I don’t know if
that restriction is useful, but in case it would be used for that purpose, it would be hijacking the
readonly marker for a something it wasn’t intended for.
* The main purpose of the abstract keyword is to prevent a class to be instantiated,
which (in case of static class) is more semantically described by the static marker.
Beyond that, it just allows to declare a method that, 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
used directly.
----
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 example is stdClass (which has no member at all, even if their
instances may have properties).
—Claude