On Mon, Jun 24, 2024 at 10:22 PM Bilge <bi...@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 `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.
