Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123919 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 498301AD8EA for ; Thu, 27 Jun 2024 04:10:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719461479; bh=mKIy29Lty6Td/FON3hSLLP7aAkP0/vvM05gKX1GnL/w=; h=From:Subject:Date:In-Reply-To:Cc:To:References:From; b=SarNp7xP3K5SzqUVzum3cIH9hdaY9bo/8arD9JNbVQzXgleu52OD1KKHM0VKdHJ0C gvZ09rKCL81mro0VJQ7GYTc/Gu4AmPOcUynsNJIYUdl9U36ACmLDUE+3IAq074ADki TN0ELOQ95RJQyaK66x2qxoE9Ac2uEyi0WX0xqqGdqlCvc0hVI0s+rco2IihUAfkMjP G3KCxzhDPY4X7sIzWVcYSU5L1V8JXm/PCT9Z3/xNnLYYe2/CJbtQ+J5DgiICpYhPPY Ls3n297Gx/dlBV5eEWABHm4WLNoPmGH+nMZurQcG1WeG14Q1Mpx1kUZ0054zUIvfXX U7mUkUFNoMfZg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 8DF0C180CF6 for ; Thu, 27 Jun 2024 04:11:16 +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 ; Thu, 27 Jun 2024 04:11:13 +0000 (UTC) Received: from smtpclient.apple (unknown [49.48.245.197]) by mail1.25mail.st (Postfix) with ESMTPSA id 8EF9A6032F; Thu, 27 Jun 2024 04:09:47 +0000 (UTC) Message-ID: <97BA9681-FA0A-4929-A6F4-67DF4820ADBF@koalephant.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_3F909FE6-82F8-4F02-90CF-406209487688" 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: Thu, 27 Jun 2024 11:09:34 +0700 In-Reply-To: <662F259B-D125-48EA-8AA0-1DC8BECA4C09@newclarity.net> Cc: Claude Pache , php internals To: Mike Schinkel References: <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com> <882BD9E0-42E9-4C84-A144-7C1DFC4CE5EB@newclarity.net> <662F259B-D125-48EA-8AA0-1DC8BECA4C09@newclarity.net> X-Mailer: Apple Mail (2.3774.600.62) From: php-lists@koalephant.com (Stephen Reay) --Apple-Mail=_3F909FE6-82F8-4F02-90CF-406209487688 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 27 Jun 2024, at 10:11, Mike Schinkel wrote: >=20 > Hi Stephen, >=20 >> On Jun 26, 2024, at 4:26 AM, Stephen Reay > wrote: >>=20 >> This is an example of code that works today (and all the way back to = 5.0): https://3v4l.org/4EKo2 >>=20 >> The class hierarchy embody the type of classes this RFC is about: = only static members, no instantiation.=20 >>=20 >> The *implemented methods* can be called statically, regardless of = whether the class they're implemented in is abstract or not. The = *abstract methods* cannot be called directly. >>=20 >> So these classes would be a candidate for the `static` class keyword = (or Attribute) - except they can't, if calls to implemented methods on = abstract classes are disallowed. Because the Base::a() method has been = publicly callable, for potentially as long as 20 years = next month. >>=20 >> My point here is that if someone wants to prohibit calling public = static methods on abstract classes *with* the static keyword, that's = going be inconsistent with how it's worked for the last 20 years (i.e. = on classes that were 'static' in intent but not syntactically), or if it = applies the change everywhere it's going to be a BC break. >=20 > It seems what you are asking about is downstream from the reason I = stated that I made the argument in the first place, which AFAICT you did = not acknowledge. That leaves me unsure of your position on a precursor = topic to your above stated objections. >=20 > As stated, my primary (initial) reason for arguing that `abstract = static` should disallow calling static methods using the class name of = the static class marked abstract =E2=80=94 as my earlier example of = calling `Base::foo()` illustrated` =E2=80=94 was in response to the = argument against allowing `abstract` with `static` because =E2=80=94 in = Claude's words =E2=80=94 it would "have no real semantic meaning for = static class; their effects on static members are only consequences of = their intended meaning on non-static class." I have copied his complete = words on that topic below: >=20 >> On Jun 24, 2024, at 4:27 AM, Claude Pache > wrote: >>=20 >> Should a static class be marked `abstract`? I think not, because = those have no real semantic meaning for static class; their effects on = static members are only consequences of their intended meaning on = non-static class: >>=20 >> * 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 > Thus my argument supporting `abstract static` was addressing his = objections by suggesting that we could have an `abstract static class` = declaration *disallow* calling any of the `static` methods of the class = using the name of the class declared `abstract` given that it would in = fact not cause any BC breaks with untouched code.=20 >=20 > Before you repeat your objections to disallowing, permit me to ask you = which of the following upstream arguments you are making? Is your = position that we should: >=20 > 1. Disallow `abstract` on `static` as Claude argued? > 2. Allow `abstract static` in spite of Claude's argument against it? >=20 > Also, if you answer "2. Allow `abstract static`" then please how do = you address Claude's objections? >=20 > Once I am clear of your position on two above I will address your = objections stated in your most recent response to me, which I quoted at = the beginning of this email. Thank you in advance for the clarity. >=20 > -Mike Hi Mike, To answer your question: I believe `abstract static` should be allowed, = because the "objection" mis-characterises a particular aspect of them as = an unintended consequence, when there's evidence to show that's not that = case. Claude essentially dismisses the use of abstract static methods: >> only consequences of their intended meaning on non-static class In v5.2 a strict standards notice was added regarding the use of = abstract static methods in classes. No notice was ever shown when = they're used in interfaces. In v7 this notice was removed (via = https://wiki.php.net/rfc/reclassify_e_strict#abstract_static_methods) = because, as Nikita noted at the time: > We currently allow the use of abstract static functions in interfaces, = as such it is inconsistent to not allow them as abstract methods. By = using late static binding a method in the abstract class can reasonably = depend on the existence of a static method in a superclass.=20 That to me says this is an intended feature, and not an unintended = consequence. Cheers Stephen=20 --Apple-Mail=_3F909FE6-82F8-4F02-90CF-406209487688 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 27 Jun 2024, at 10:11, Mike Schinkel = <mike@newclarity.net> wrote:

Hi = Stephen,

On Jun 26, 2024, at 4:26 AM, = Stephen Reay <php-lists@koalephant.com> = wrote:

This is an example of code that works today (and all the way back = to 5.0): https://3v4l.org/4EKo2

The class hierarchy embody the type of classes this RFC = is about: only static members, no instantiation. 

The *implemented methods* can be called statically, = regardless of whether the class they're implemented in is abstract or = not. The *abstract methods* cannot be called directly.

So these classes would be a candidate for the `static` = class keyword (or Attribute) - except they can't, if calls to = implemented methods on abstract classes are disallowed. Because the = Base::a() method has been publicly callable, for potentially as long as = <checks notes>  20 years next month.

My point here is that if someone wants to prohibit = calling public static methods on abstract classes *with* the static = keyword, that's going be inconsistent with how it's worked for the last = 20 years (i.e. on classes that were 'static' in intent but not = syntactically), or if it applies the change everywhere it's going to be = a BC break.

It seems what = you are asking about is downstream from the reason I stated that I made = the argument in the first place, which AFAICT you did not acknowledge. = That leaves me unsure of your position on a precursor topic to your = above stated objections.

As stated, my primary = (initial) reason for arguing that `abstract static` should disallow = calling static methods using the class name of the static class marked = abstract =E2=80=94 as my earlier example of calling `Base::foo()` = illustrated` =E2=80=94 was in response to the argument against allowing = `abstract` with `static` because =E2=80=94 in Claude's words =E2=80=94 = it would "have no real semantic meaning for static class; their effects = on static members are only consequences of their intended meaning on = non-static class."  I have copied his complete words on that topic = below:

On Jun 24, 2024, at 4:27 AM, Claude Pache <claude.pache@gmail.com> = wrote:

Should a static class be marked `abstract`? I think = not, because those have no real semantic meaning for static class; their = effects on static members are only consequences of their intended = meaning on non-static class:

* 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.

Thus my argument = supporting `abstract static` was addressing his objections by suggesting = that we could have an `abstract static class` declaration *disallow* = calling any of the `static` methods of the class using the name of the = class declared `abstract` given that it would in fact not cause any BC = breaks with untouched code. 

Before you repeat = your objections to disallowing, permit me to ask you which of the = following upstream arguments you are making?  Is your position that = we should:

1. Disallow `abstract` on `static` as = Claude argued?
2. Allow `abstract static` in spite of =  Claude's argument against = it?

Also, if you answer "2. Allow = `abstract static`" then please how do you address Claude's = objections?

Once I am clear of your position on = two above I will address your objections stated in your most recent = response to me, which I quoted at the beginning of this email. =  Thank you in advance for the = clarity.

-Mike

Hi Mike,


To answer your = question: I believe `abstract static` should be allowed, because the = "objection" mis-characterises a particular aspect of them as an = unintended consequence, when there's evidence to show that's not that = case.


Claude essentially = dismisses the use of abstract static = methods:

only = consequences of their intended meaning on non-static = class

In v5.2 a = strict standards notice was added regarding the use of abstract static = methods in classes. No notice was ever shown when they're used in = interfaces.  In v7 this notice was removed (via https://wiki.php.net/rfc/reclassify_e_strict#abstract_static_methods) because, as Nikita noted at the = time: