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 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.
Great point, readonly and static should be mutually exclusive and generate a compile-time error, since readonly static properties are not supported.
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.
I thought that was covered off, but I'll see if I can word it better.
* 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.
Great point, I'll include that detail.I think we're also missing a similar detail with respect to dynamic properties, which should of course also be forbidden.
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.
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 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.
I tend to find inheritance is not a very useful concept in static contexts, but others have already pointed out that some have found uses for it. Due 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 mutual 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 example is stdClass (which has no member at all, even if their instances may have properties).
Do you mean it is not simply sufficient for a class to be regarded as implicitly static by virtue of the fact that it has no instance members? I'm not sure I agree, but I may be missing something. If we extend stdClass then we gain nothing, and our class so extending it can still be safely marked static, can it not? Please elaborate so I might understand better.
Kind regards,
Bilge