Re: RFC Proposal - static modifier for classes

On Mon, Nov 20, 2023, at 7:52 AM, Rowan Tommins wrote: > On 19 November 2023 21:28:08 GMT, Lanre Waju <lanre@online-presence.ca> wrote: >>Hi, similar to the abstract and readonly modifiers to classes (similar in syntax only), I >>propose a class level "static" modifier that ensures: > > > Hi Lanre, > > There was a proposal for this several years ago which was declined at > the voting stage: https://wiki.php.net/rfc/abstract_final_class > > That doesn't mean we can't look again, but any new proposal would need > to at least address the reasons the previous one was declined. I > believe these are the relevant discussion threads: > https://externals.io/message/79211 > https://externals.io/message/79338 > https://externals.io/message/79601 > > My memory is that one of the main points against was that a class with > only static methods is just a namespace, and you can already put > functions directly in a namespace. The only issue being that we don't > have good autoloading support for such functions, and that's a whole > different problem... I wasn't a voter at the time, but I would absolutely vote against a static class RFC today, for largely the same reasons. On Mon, Nov 20, 2023, at 8:35 AM, Lanre Waju wrote: > 3. It is entirely opt-in. If you hold reservations about using static > classes, you can simply choose not to use them. This is a spurious and disingenuous argument, even if it gets trotted out frequently on many RFCs. I'm not picking on you in particular here, but it's a bad argument to use, period, 99% of the time, no matter who is saying it. Rowan already mentioned the maintenance burden that it entails. I'll go a step further. We've already seen that "readonly" properties have their uses, though not everyone uses them. So far so good. But readonly also was implemented with a stealth extra asymmetric visibility implication, which made the design and implementation of real asymmetric visibility harder, and very likely contributed to that RFC not passing due to the perceived extra complexity of working around readonly's shortcomings. Similarly, if we add a static marker to classes, that means all future improvements to classes need to consider "but what if the class is static?" Eg, there was discussion a while back about data classes. What happens if you have a static data class? Is that a syntax error? Does it work? If it works, what does "work" mean? What about sealed classes? Can you have a sealed static class? What would that mean? Those are questions that would need to be answered, because this feature exists. It impacts all users, too, because almost no one builds a 100% self-written codebase anymore. 99% of projects are 80% someone else's code via Composer packages large and small, which means every language feature they use, you need to be aware of how to use. If some library has a static class as part of its API, I am now forced to work with static classes, whether I like it or not. Certainly, many features are worth the extra burden to maintain and to train for. We pass new RFCs all the time that we collectively decide are worth it, I've proposed several, etc. But "if you don't like it, just ignore it" has always been a misleading and ignorant claim to make about any proposed feature. "The implications are small so you probably won't need to worry outside of these situations" is a valid argument to make (and to disagree about), but that's a different thing. > The proposal is designed with the intention of improving code clarity, > reinforcing design principles, and establishing a clear and standardized > approach to expressing the intended usage of a class. While I advocate > for member properties and methods to be implicitly static, I am open to > understanding alternative viewpoints on why this might not be the > optimal choice. Emphasizing: > reinforcing design principles, Which is exactly the problem. All-static classes *are a bad design principle that should not be encouraged*. They're a namespace cheat, not a good design. They should be discouraged, not encouraged. If the methods are pure functions, then they really ought to just be namespaced functions. Those work. They're fine. Autoloading is frankly mostly solved by using the files block in your composer.json's autoload config, and then you don't need to care. Pure functions are OK. The obsession with avoiding functions in many parts of PHP culture is really not to its credit. (And I admit going through my own phase where I thought that; it was incorrect then, it's incorrect now, and it's been incorrect pretty much since 5.5 gave us an always-on opcache.) If the methods are non-pure... then it has no business being a static method. It needs to be an object method, otherwise it breaks testing. Yes, there are a lot of older libraries and APIs that use static methods in a stateful way, or make IO calls to a remote service, etc. Those libraries are wrong. Period. Language features that encourage that anti-pattern are anti-features. Those should be instantiated objects which can be injected and mocked and use mocks and be tested easily and so on. To be clear, static methods have their place. I'm not against static methods. I'm against static methods as a cheap discount-bin namespace, as that shows a lack of understanding of the language and of OOP design. Yet that is precisely what static class would be. If we really wanted the language to reinforce good design principles, we would make a class that has only static methods and nothing else a syntax error. :-) I do not proposed we actually do that, but that's what "reinforcing design principles" would mean in practice. --Larry Garfield