Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123810 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id A71051A009C for ; Tue, 25 Jun 2024 08:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719304974; bh=wsBgUHbHRsNw/XaefnOS5BVmKWanZk5/54nyGGpn+r4=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=DCGND7V5wC2XqHUwFi8kgxbE1b34quqUsVRJqMdhw9tXKSxAjISkz40fqV9mCF9Az /YdOzq4YuEVYviDsB69RE/0tjHOoUDPaFOcivORSYpkLc8iGslo18HcItkqesMkNaG ZxMP07EDtMRdxjuYKsjv/+U0Avxui3m0CJB4zgDIu5l7Gh0Ei6etLFASsP0dMwZGeM ejdbHBYCh3lsXp7q7f7HdqwSg6i8YbV9DUKFRWcZEG4Lum8/0rQhGDnE+R3kSWibRH Ut1GJK7jC25tK0uwODkTCpQkLQI3whFpid5cw7w0GCOhqbn5PJB9FEbpKAu0TRfiY/ jG8Q9V08Gukwg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 38A7E18068C for ; Tue, 25 Jun 2024 08:42:53 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,DMARC_MISSING, HTML_MESSAGE,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail1.25mail.st (mail1.25mail.st [206.123.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Tue, 25 Jun 2024 08:42:52 +0000 (UTC) Received: from smtpclient.apple (unknown [49.48.245.122]) by mail1.25mail.st (Postfix) with ESMTPSA id 8670460354; Tue, 25 Jun 2024 08:41:22 +0000 (UTC) Message-ID: <9B9777A5-6633-4826-9133-42DCB8FAA79E@koalephant.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_151EFD9B-9B89-4587-A51B-E2207A9A76C1" Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: [PHP-DEV] [RFC] Static class Date: Tue, 25 Jun 2024 15:41:08 +0700 In-Reply-To: Cc: Mike Schinkel , Claude Pache , ayesh@php.watch, php internals To: Bilge References: <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com> <882BD9E0-42E9-4C84-A144-7C1DFC4CE5EB@newclarity.net> X-Mailer: Apple Mail (2.3774.600.62) From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_151EFD9B-9B89-4587-A51B-E2207A9A76C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, > On 25 Jun 2024, at 15:03, Bilge wrote: >=20 > Hi guys, >=20 > 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. >>=20 >> 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 >=20 Cheers Stephen=20= --Apple-Mail=_151EFD9B-9B89-4587-A51B-E2207A9A76C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On 25 Jun 2024, at 15:03, Bilge = <bilge@scriptfusion.com> wrote:

=20 =20
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 
= --Apple-Mail=_151EFD9B-9B89-4587-A51B-E2207A9A76C1--