> On 8 Jul 2024, at 14:42, Bilge <[email protected]> wrote:
>
> On 08/07/2024 01:16, Mike Schinkel wrote:
>> Congrats on getting it to this point.
> Thanks. It's been an adventure :^)
>
>> I support this in all but the RFC's restriction on abstract, as I have
>> previously mentioned on the list.
> I must have missed a key point here. Let's suppose we're writing a follow-up RFC to
> permit static and abstract together. In as few sentences as possible, what
> is the benefit conferred to the developer?
>
> Cheers,
> Bilge
>
Hi,
I'm sure Mike has his own answer for this, but I'm going to reiterate mine again, because
it apparently wasn't really understood the first several times I said it:
The reasons are two fold:
(a) so that a static class can declare abstract methods either explicitly or implicitly (by
implementing an interface without providing concrete implementations of all methods in the
interface)
(b) to keep consistency with regular classes.
The suggested static keyword for classes doesn't introduce any additional behaviour that
isn't already possible, it just prevents some uses without the need for boilerplate - the main
purpose is to "signify developer intent".
The actual behaviour applied to "static" classes is already possible in PHP by simply
omitting any instance members and declaring a private constructor. These classes work fine with the
abstract keyword. There are no ambiguities, no gotchas or foot guns, there is nothing confusing.
It's a standard part of class hierarchy.
So really the question should be: why do you feel the need to *disallow* a combination that has no
technical issues, and works already? If you're going to disallow abstract why not disallow any
class inheritance at all? Because that's what abstract relates to: class hierarchy. Why remove
some support but keep the rest?
Cheers
Stephen