Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123802 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 F359B1A009C for ; Tue, 25 Jun 2024 03:18:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719285570; bh=FG16vxBh9ojbhN1eFlGOzgI7N2K+alQ+NVPscccXUgs=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=ZMC8E2hGHiB1Od9J8/zJNGbC/FBN+11+zDC5y5EK3SXgjngRw1VELrjgYAdfZ49IV W0vtEh8Tf8ewgRdSq8S1GwZyjoansddkb7VeXnijjnQ0TmpzYm+Ol2lakuFJ7lYXYz wYfFqbp+h714YDx/1PRT5ScdHgbvQHQGsWEQisi1COp/MZHrADIGHC4CurgQNu5eft W4iFhgdqL+HKrcNpE9S6t4cIwUv2pDld7+11MSiypcLu3QXNXnz0qMog9ccksEP4bF VcEqyAiuizyefQcBWOJ9/Xthww2c1OPv4RlINTFqv+bvy0FuVjcLO5SzcNIPxRlAer WR0Qxct9IbaXQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 017CC18005C for ; Tue, 25 Jun 2024 03:19:26 +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 03:19:25 +0000 (UTC) Received: from smtpclient.apple (unknown [49.48.245.122]) by mail1.25mail.st (Postfix) with ESMTPSA id DE4E260350; Tue, 25 Jun 2024 03:17:55 +0000 (UTC) Message-ID: Content-Type: multipart/alternative; boundary="Apple-Mail=_C1C6888D-AF6E-4EA5-8FBE-5C1330064992" 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 10:17:42 +0700 In-Reply-To: <882BD9E0-42E9-4C84-A144-7C1DFC4CE5EB@newclarity.net> Cc: Claude Pache , ayesh@php.watch, Bilge , php internals To: Mike Schinkel 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=_C1C6888D-AF6E-4EA5-8FBE-5C1330064992 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25 Jun 2024, at 09:22, Mike Schinkel wrote: >=20 >> On Jun 24, 2024, at 3:53 AM, Ayesh Karunaratne > wrote: >> - Why is it a class-level flag and not an attribute (similar to the >> `#[Override]` attribute in PHP 8.3) ? >=20 > =46rom 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. >=20 > Given the concept already exists in keywords I would strongly argue = that it makes no sense to introduce as an attributes in core PHP. =20 >=20 > Attributes are great for concepts new to PHP, IMO, but not for = existing concepts already part of PHP implemented with keywords. >=20 >> On Jun 24, 2024, at 4:27 AM, Claude Pache > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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.=20 >=20 > -Mike=20 >=20 > 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=20 --Apple-Mail=_C1C6888D-AF6E-4EA5-8FBE-5C1330064992 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 25 Jun 2024, at 09:22, Mike Schinkel = <mike@newclarity.net> wrote:

On Jun 24, 2024, at = 3:53 AM, Ayesh Karunaratne <ayesh@php.watch> = wrote:
- Why is it a class-level flag and not an attribute = (similar to the
`#[Override]` attribute in PHP 8.3) = ?

=46rom 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.pache@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 

= --Apple-Mail=_C1C6888D-AF6E-4EA5-8FBE-5C1330064992--