> On 25 Jun 2024, at 09:22, Mike Schinkel <m...@newclarity.net> wrote: > >> On Jun 24, 2024, at 3:53 AM, Ayesh Karunaratne <ayesh@php.watch >> <mailto:ayesh@php.watch>> wrote: >> - Why is it a class-level flag and not an attribute (similar to the >> `#[Override]` attribute in PHP 8.3) ? > > From my perspective that would create much confusion among every PHP > developer who has not committed to memory when to use `static` as a class > keyword and when to use it as an attribute. > > Given the concept already exists in keywords I would strongly argue that it > makes no sense to introduce as an attributes in core PHP. > > Attributes are great for concepts new to PHP, IMO, but not for existing > concepts already part of PHP implemented with keywords. > >> On Jun 24, 2024, at 4:27 AM, Claude Pache <claude.pa...@gmail.com >> <mailto:claude.pa...@gmail.com>> wrote: >> * 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. > > Given a primary purpose for being able to declare a class `static` is to > signal intent, disallowing `abstract static` classes seems at odds with that > goal. > > Of course it is currently true that `static` methods of `abstract` classes > can be called from outside a class and its class hierarchy, so if we allow > declaring `abstract static` classes then it would never in the future be > possible to lock down calls of `static` methods to those `abstract` classes. > > So IMO it would be better to disallow calling `static` methods from outside a > declared `abstract static` class and its inheritance hierarchy as part of > this RFC. That would be backward compatible since there are currently no > classes that are declared in that manner. Doing otherwise would force those > who want to declare a class as both `static` and `abstract` to have to make a > choice rather than being able to signal their full intent. Which brings us > back to the "implied" vs. "explicitly declared" bifurcation I mentioned in a > prior email. > > BTW, I am assuming it is technically possible to disallow calling methods for > classes declared both `abstract` and `static` without considerable difficulty > in implementation and without creating a significant drain on performance. > > -Mike > > P.S. I would argue the same for `readonly static` properties, but as that > seems those would require an involved discussion about the exact rules to > implement I am demurring on that topic.
Hi Mike, > So IMO it would be better to disallow calling `static` methods from outside a > declared `abstract static` class Can you explain what you mean by this, or more specifically the "why". What (implied wrong/bad) scenario are you trying to prevent, by disallowing a static method on an abstract class to be called? As you point out, it's already possible to call (public) static methods on abstract classes, the same as it's possible to call (public) static methods without instantiating a regular class. So why should static abstract classes be different? If the static method shouldn't be called publicly, it shouldn't be public. Are you suggesting that public static methods shouldn't be callable on *any* abstract class? If so, this sounds like a huge BC break, and if not, it sounds like a confusing "if-then-but-why" scenario. I agree that the `static` keyword is a much better fit here, however there is one other aspect here that may come into it (as much as I prefer the keyword approach): the Attribute approach is backwards compatible (with a polyfill) to let code using this feature also run on previous PHP releases. Given that this is mostly intended as a way to signal intent about a pattern that's already in use, this may be significant for library authors. Personally (as a library author) I don't think that ability is worth the weirdness of an attribute vs a keyword, but it may be more important for others who are voting, and I'd rather have the feature with slightly odd syntax rather than not at all. Cheers Stephen
