Re: RFC Proposal - static modifier for classes

Am 20.11.2023 um 22:00 schrieb Lanre Waju <lanre@online-presence.ca>: > I will have to disagree with everything you said: Side-note: This is IMHO not a good intro into a discussion ;-) > 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? That is his point: The benefit has to outweigh the debt and for something like a class modifier this can lead to a matrix of possible combinations, complication things down the line. >>> 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. I’m with Larry there: Being able to just ignore new features is sometimes helpful (i.e. avoids the discussion about BC) but not a strong argument on *why* something should be added. This lists very much also cares about the implementation and maintenance costs as well as the simplicity/consistency of PHP. Being opt-in just does not carry much weight in that context. >> 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. Being a long time member of this list (even though with only very occasional contributions to the source code) I have to say: There is a wide range of experience in both language design and implementation (for both PHP and in general) represented here, some members coming from an almost exclusively language-user point of view. And that is a great thing! But I’d recommend to not underestimate the knowledge contributed by people who have been involved for some time and possibly even learned from previous mistakes :-) Having said all that I just wanted to add that I would most probably vote against static classes even though we use class-as-a-namespace here sometimes but still don’t feel the need for it to being a language feature for the reasons mentioned by Rowan and Larry. Regards, - Chris