Hi guys,
On 25/06/2024 04:17, Stephen Reay wrote:
Given a primary purpose for being able to declare a class
`static` is to *signal intent*, disallowing `abstract static`
classes seems at odds with that goal.
What is the /intent/ of `abstract static`? How is such intent different
from just `static`?
I agree that the `static` keyword is a much better fit here, however
there is one other aspect here that may come into it (as much as I
prefer the keyword approach): the Attribute approach is backwards
compatible (with a polyfill) to let code using this feature also run
on previous PHP releases. Given that this is mostly intended as a way
to signal intent about a pattern that's already in use, this may be
significant for library authors.
Personally (as a library author) I don't think that ability is worth
the weirdness of an attribute vs a keyword, but it may be more
important for others who are voting, and I'd rather have the feature
with slightly odd syntax rather than not at all.
When I first saw the proposal to use an attribute instead of the
keyword, I thought it absurd, but this idea has now been entertained by
three people, and for the first time I have seen a compelling argument
in favour of (early adoption). I must admit, I was too quick to judge
this one. I had not considered that libraries will still not be able to
use the `static` modifier with classes unless and until they drop
support for PHP < 8.4, which may take a while! Of course, it is still of
real benefit to first-party proprietary projects whom have upgraded.
Nevertheless, the allure of early adoption is curious, and made me
wonder whether we could do both, just to support early adoption in a
backwards-compatible manner. However, this would be unprecedented and
most likely not accepted; never before has the same feature been
implemented two ways just to appease early adopters. I think the best
compromise would be, for anyone so eager, to implement such support in
community tools, e.g. PHPStan. That is, it should be perfectly possible
to enforce the core semantics of the static class feature with a
userland attribute and the necessary logic in static analysis tools,
provided the library is well behaved and doesn't do anything too weird
with variable variables, references, reflection or unserialize() to
deliberately circumvent the restriction.
Cheers,
Bilge
