I wouldn't support this, personally. I'm not a voter but I mean just in terms of gauging community feel about the proposal, without unnecessarily repeating what's already been said I just want to register that I'm in agreement with Larry and Kamil's comments.
What static classes would achieve goes against the design principles of what a class is and what it's for. Others have noted we already have an adequate namespacing system and via Composer which is a de facto standard in almost all PHP projects today, a means to autoload namespaced functions. But more than that, I think for me - look, I get a lot of language features which are sincerely useful can be argued to be just convenient syntax sugar for things you could technically already do another way. But when I consider features like readonly properties, constructor promotion and readonly classes, I think the functional change goes beyond just syntax sugar. You're getting an enormous saving versus say, trying to make a class with all properties readonly in PHP 7.4. It's not just a little bit of boilerplate trimmed down, it's you now have to write one line of code instead of fifty. So even if I supported the idea of static classes in principle, I'd still be looking at it and thinking really the only convenience, the only syntax sugar here is that you now have to type the word static N-1 fewer times where N is the number of properties and functions in your class. This is not a huge benefit or saving to me. While I wouldn't encourage anyone to design their code this way, for the same reasons Larry has articulated, if you want to design your code this way you already can at basically the same cost of your time and effort and same cost to the PHP engine. I think there'd need to be some persuasively more substantial gain for either the developer or the execution of a script for this proposal to be worth anything. Thanks. -David
