Am 20.11.2023 um 22:00 schrieb Lanre Waju <la...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
