On Mon, Jun 24, 2024 at 10:22 PM Bilge <[email protected]> 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.