Hi,
> On 25 Jun 2024, at 15:03, Bilge <[email protected]> wrote:
>
> Hi guys,
>
> On 25/06/2024 04:17, Stephen Reay wrote:
>>> 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.
> What is the intent of abstract static? How is such intent different from just
> static?
Sorry I should have been clearer. It isn't that abstract represents an intent,
it's that adding static is mostly about conveying intent - and thus there's
no *technical* reason that *any* existing class with only static members can't be marked as a
static class, so why introduce an artificial barrier if that class happens to already be abstract?
It's already possible to have a class with only static members, that is abstract, and call the
public static methods of it. It's also possible to have a class that partially implements an
interface that has static methods on it. Unless your RFC is going to propose preventing calling
static methods on *all* abstract classes it's a needless complication when there's no
technical reason to do so.
>> 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.
> When I first saw the proposal to use an attribute instead of the keyword, I thought it absurd,
> but this idea has now been entertained by three people, and for the first time I have seen a
> compelling argument in favour of (early adoption). I must admit, I was too quick to judge this one.
> I had not considered that libraries will still not be able to use the static modifier
> with classes unless and until they drop support for PHP < 8.4, which may take a while! Of course,
> it is still of real benefit to first-party proprietary projects whom have upgraded. Nevertheless,
> the allure of early adoption is curious, and made me wonder whether we could do both, just to
> support early adoption in a backwards-compatible manner. However, this would be unprecedented and
> most likely not accepted; never before has the same feature been implemented two ways just to
> appease early adopters. I think the best compromise would be, for anyone so eager, to implement such
> support in community tools, e.g. PHPStan. That is, it should be perfectly possible to enforce the
> core semantics of the static class feature with a userland attribute and the necessary logic in
> static analysis tools, provided the library is well behaved and doesn't do anything too weird
> with variable variables, references, reflection or unserialize() to deliberately circumvent the
> restriction.
Yes it should be possible to use a user land attribute or phpdoc tag or what have, but that's
*already* true. You've essentially just made a case against your own RFC - that it can mostly
be done already in userland.
The entire appeal of a *builtin* attribute would be that it's something you could apply *now*
(as in today, June 2024) and know that it won't *break* anything, while having some
{compile,run} time benefits in later versions (e.g. enforcing static-only, and inability to
instantiate).
Like I said, I much prefer the keyword syntax - but I also recognise that others may have different
priorities in terms of supporting older language versions, which is why I think that aspect is worth
consideration (perhaps a secondary vote, or an informal vote to gauge consensus?), because too many
good RFCs get rejected over small details.
> Cheers,
> Bilge
>
Cheers
Stephen