> On 27 Jun 2024, at 10:11, Mike Schinkel <[email protected]> wrote:
>
> Hi Stephen,
>
>> On Jun 26, 2024, at 4:26 AM, Stephen Reay <[email protected] <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> 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