Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123801
Message-ID: <882BD9E0-42E9-4C84-A144-7C1DFC4CE5EB@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_14FBFB21-A0E3-4382-9D59-EB4444809A89"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [RFC] Static class
Date: Mon, 24 Jun 2024 22:22:07 -0400
In-Reply-To: <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com>
Cc: Bilge <bilge@scriptfusion.com>,
 php internals <internals@lists.php.net>
To: Claude Pache <claude.pache@gmail.com>,
 ayesh@php.watch
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <88D83E92-94BE-4548-B398-8F5C74765FFD@gmail.com>
From: mike@newclarity.net (Mike Schinkel)


--Apple-Mail=_14FBFB21-A0E3-4382-9D59-EB4444809A89
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> 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. =20

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.=20

-Mike=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.=

--Apple-Mail=_14FBFB21-A0E3-4382-9D59-EB4444809A89
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Jun =
24, 2024, at 3:53 AM, Ayesh Karunaratne &lt;<a =
href=3D"mailto:ayesh@php.watch" class=3D"">ayesh@php.watch</a>&gt; =
wrote:</div><div class=3D"">- Why is it a class-level flag and not an =
attribute (similar to the<br class=3D"">`#[Override]` attribute in PHP =
8.3) ?</div></blockquote><div class=3D""><br class=3D""></div><blockquote =
style=3D"margin: 0 0 0 40px; border: none; padding: 0px;" class=3D""><div =
class=3D"">=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.</div><div =
class=3D""><br class=3D""></div><div class=3D"">Given the concept =
already exists in keywords I would strongly argue that it makes no sense =
to introduce as an attributes in core PHP. &nbsp;</div><div class=3D""><br=
 class=3D""></div><div class=3D"">Attributes are great for concepts new =
to PHP, IMO, but not for existing concepts already part of PHP =
implemented with keywords.</div><div class=3D""><br =
class=3D""></div></blockquote><div><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Jun 24, 2024, at 4:27 AM, Claude Pache =
&lt;<a href=3D"mailto:claude.pache@gmail.com" =
class=3D"">claude.pache@gmail.com</a>&gt; wrote:</div><div class=3D""><div=
 class=3D"">* 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.<br =
class=3D""></div></div></blockquote><div><br =
class=3D""></div></div><blockquote style=3D"margin: 0 0 0 40px; border: =
none; padding: 0px;" class=3D""><div><div>Given a primary purpose for =
being able to declare a class `static` is to <b class=3D"">signal =
intent</b>, disallowing&nbsp;`abstract static` classes seems at odds =
with that goal.</div><div><br class=3D""></div><div>Of course it is =
currently true that `static` methods of `abstract` classes <b =
class=3D"">can</b> be called from outside a &nbsp;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.</div><div><div class=3D""><br =
class=3D""></div></div><div>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. &nbsp;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 <i class=3D"">"implied"</i> vs. <i =
class=3D"">"explicitly declared"</i> bifurcation I mentioned in a prior =
email.</div><div><br class=3D""></div><div>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.&nbsp;</div><div><br =
class=3D""></div></div></blockquote>-Mike&nbsp;<div class=3D""><br =
class=3D""><div class=3D"">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.</div></div></body></html>=

--Apple-Mail=_14FBFB21-A0E3-4382-9D59-EB4444809A89--