Re: [RFC] Static class

> Le 24 juin 2024 à 01:10, Bilge <bilge@scriptfusion.com> 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