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
