> On 8 Jul 2024, at 14:42, Bilge <bi...@scriptfusion.com> 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
