> On 27 Jun 2024, at 10:11, Mike Schinkel <m...@newclarity.net> wrote: > > Hi Stephen, > >> On Jun 26, 2024, at 4:26 AM, Stephen Reay <php-li...@koalephant.com >> <mailto: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 >> >> 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 >> <mailto: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
Hi Mike, To answer your question: I believe `abstract static` should be allowed, because the "objection" mis-characterises a particular aspect of them as an unintended consequence, when there's evidence to show that's not that case. Claude essentially dismisses the use of abstract static methods: >> only consequences of their intended meaning on non-static class In v5.2 a strict standards notice was added regarding the use of abstract static methods in classes. No notice was ever shown when they're used in interfaces. In v7 this notice was removed (via https://wiki.php.net/rfc/reclassify_e_strict#abstract_static_methods) because, as Nikita noted at the time: > We currently allow the use of abstract static functions in interfaces, as > such it is inconsistent to not allow them as abstract methods. By using late > static binding a method in the abstract class can reasonably depend on the > existence of a static method in a superclass. That to me says this is an intended feature, and not an unintended consequence. Cheers Stephen
