Re: [RFC] Static class

Hi, > On 25 Jun 2024, at 15:03, Bilge <bilge@scriptfusion.com> wrote: > > 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? Sorry I should have been clearer. It isn't that abstract represents an intent, it's that adding static is mostly about conveying intent - and thus there's no *technical* reason that *any* existing class with only static members can't be marked as a static class, so why introduce an artificial barrier if that class happens to already be abstract? It's already possible to have a class with only static members, that is abstract, and call the public static methods of it. It's also possible to have a class that partially implements an interface that has static methods on it. Unless your RFC is going to propose preventing calling static methods on *all* abstract classes it's a needless complication when there's no technical reason to do so. >> 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. Yes it should be possible to use a user land attribute or phpdoc tag or what have, but that's *already* true. You've essentially just made a case against your own RFC - that it can mostly be done already in userland. The entire appeal of a *builtin* attribute would be that it's something you could apply *now* (as in today, June 2024) and know that it won't *break* anything, while having some {compile,run} time benefits in later versions (e.g. enforcing static-only, and inability to instantiate). Like I said, I much prefer the keyword syntax - but I also recognise that others may have different priorities in terms of supporting older language versions, which is why I think that aspect is worth consideration (perhaps a secondary vote, or an informal vote to gauge consensus?), because too many good RFCs get rejected over small details. > Cheers, > Bilge > Cheers Stephen