Re: RFC Proposal - static modifier for classes

I will have to disagree with everything you said: I outlined what a static class would be: A class that cannot be instantiated in which all members are implicitly static. We already have static members, so please elaborate on the maintenance burden that adding static to a class as that could help explain better, i mean what feature doesn't have technical debt associated with it? The new JIT engine?

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. If you insist, Mr. Larry.

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. Either i'm in an alternate reality where the data classes and sealed classes rfcs passed, or I've just been straw-manned. Either way, is it really that difficult to decide on as a community what a static data class implies? We have already established that a static class means all the members are static, but i can try to dumb it down for you if need be.

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. If you had told me we were allowed to pull numbers out of our asses, i would have mentioned that 100% of php users will benefit from this, Including people like you who don't necessarily see the value in it. As a user of a class, it shouldn't matter whether it's static or not, the static members will be the same as using a normal class with static members, in fact, people already simulate this in userland by making __construct private and only using static members, does that impede your ability to use such libs? How is this forcing you to use static classes? The dev of said library(which no one is forcing you to use) would be the one who made that call. After which it's your call to decide whether or not the library suites you. I don't see any forcing here but do enlighten me.

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.

They could be used as a namespace cheat yes, they could be used wrongly, but that doesn't mean it doesn't have any valid uses or make it inherently bad. You remind me of the people that literally never use inheritance because they read "inheritance over composition" somewhere. Please elaborate more on why it's a bad design principle.

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.

Again that is your opinion, yet you speak it like it's fact. I guess all those libraries are wrong because Mr. Larry thinks so. So before you write your next library, ask yourself "what would larry do".

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. And i guess you are also the authority in terms of what design principles should and shouldn't be reinforced, I will also keep that in mind.

I am still holding out for a productive conversation based on facts, regardless, you are entitled to your opinions on the matter. Cheers, Lanre. On 2023-11-20 12:59 p.m., Larry Garfield wrote:

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