Hi Stephen, > On Jun 26, 2024, at 4:26 AM, Stephen Reay <php-li...@koalephant.com> wrote: > > This is an example of code that works today (and all the way back to 5.0): > https://3v4l.org/4EKo2 <https://3v4l.org/4EKo2> > > The class hierarchy embody the type of classes this RFC is about: only static > members, no instantiation. > > The *implemented methods* can be called statically, regardless of whether the > class they're implemented in is abstract or not. The *abstract methods* > cannot be called directly. > > So these classes would be a candidate for the `static` class keyword (or > Attribute) - except they can't, if calls to implemented methods on abstract > classes are disallowed. Because the Base::a() method has been publicly > callable, for potentially as long as <checks notes> 20 years next month. > > My point here is that if someone wants to prohibit calling public static > methods on abstract classes *with* the static keyword, that's going be > inconsistent with how it's worked for the last 20 years (i.e. on classes that > were 'static' in intent but not syntactically), or if it applies the change > everywhere it's going to be a BC break.
It seems what you are asking about is downstream from the reason I stated that I made the argument in the first place, which AFAICT you did not acknowledge. That leaves me unsure of your position on a precursor topic to your above stated objections. As stated, my primary (initial) reason for arguing that `abstract static` should disallow calling static methods using the class name of the static class marked abstract — as my earlier example of calling `Base::foo()` illustrated` — was in response to the argument against allowing `abstract` with `static` because — in Claude's words — it would "have no real semantic meaning for static class; their effects on static members are only consequences of their intended meaning on non-static class." I have copied his complete words on that topic below: > On Jun 24, 2024, at 4:27 AM, Claude Pache <claude.pa...@gmail.com> wrote: > > Should a static class be marked `abstract`? I think not, because those have > no real semantic meaning for static class; their effects on static members > are only consequences of their intended meaning on non-static class: > > * The main purpose of the `abstract` keyword is to prevent a class to be > instantiated, which (in case of static class) is more semantically described > by the `static` marker. Beyond that, it just allows to declare a method that, > if implemented by a subclass, should have a compatible signature. Most > notably, it does not prevent the other static members of the class to be used > directly. Thus my argument supporting `abstract static` was addressing his objections by suggesting that we could have an `abstract static class` declaration *disallow* calling any of the `static` methods of the class using the name of the class declared `abstract` given that it would in fact not cause any BC breaks with untouched code. Before you repeat your objections to disallowing, permit me to ask you which of the following upstream arguments you are making? Is your position that we should: 1. Disallow `abstract` on `static` as Claude argued? 2. Allow `abstract static` in spite of Claude's argument against it? Also, if you answer "2. Allow `abstract static`" then please how do you address Claude's objections? Once I am clear of your position on two above I will address your objections stated in your most recent response to me, which I quoted at the beginning of this email. Thank you in advance for the clarity. -Mike
