Hi Stephen,
> On Jun 26, 2024, at 4:26 AM, Stephen Reay <[email protected]> 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 <[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