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
