Re: [RFC] Static class

On Mon, Jun 24, 2024 at 10:22 PM Bilge <bilge@scriptfusion.com> wrote: > > 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 �����O�q > ��n�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 Hey Bilge, > 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. 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.