Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123648
Message-ID: <F55F8E78-AC18-454E-96B0-7BB28B0190E0@newclarity.net>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_B0F69558-DCDD-43EE-9A56-6EF15D045034"
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] Static class
Date: Mon, 17 Jun 2024 10:41:54 -0400
In-Reply-To: <a380fa4d-4014-4f20-9c96-ac8e6789c9e2@scriptfusion.com>
Cc: internals@lists.php.net
To: Bilge <bilge@scriptfusion.com>
References: <0cf69a14-f1b5-4077-9d91-d7b579485eec@scriptfusion.com>
 <936e1aa3-48cc-4552-9f68-676ebcdeb596@rwec.co.uk>
 <04ae10a2-ceae-4996-a7fe-9b38d2f81ca2@scriptfusion.com>
 <82601236-3228-491E-B776-457331B41C6B@newclarity.net>
 <a5aad48e-5328-4c19-903b-3c3772dcdd7b@scriptfusion.com>
 <a380fa4d-4014-4f20-9c96-ac8e6789c9e2@scriptfusion.com>
From: mike@newclarity.net (Mike Schinkel)


--Apple-Mail=_B0F69558-DCDD-43EE-9A56-6EF15D045034
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

> On Jun 17, 2024, at 8:54 AM, Bilge <bilge@scriptfusion.com> wrote:
> Furthermore, for absolute clarity and the avoidance of doubt, I =
believe this guiding principle can be enshrined on the following single =
sentence:
>=20
>     "We cannot remove features from a static class that would =
otherwise be present in a standard class."
>=20
> I believe following this principle we will arrive at the best =
implementation of static classes
>=20

A great principle, yes, but needing a small caveat:

 "...excepting features that by-nature are not relevant to the static =
class use-case, such as instance-based magic methods like `__get()`, =
`__set()`` and `__construct()`."

That might have been implied, but good to make it explicit.

-Mike


--Apple-Mail=_B0F69558-DCDD-43EE-9A56-6EF15D045034
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset=us-ascii

<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Jun 17, 2024, at 8:54 AM, Bilge &lt;<a href="mailto:bilge@scriptfusion.com" class="">bilge@scriptfusion.com</a>&gt; wrote:</div><div class=""><div class=""><p class="">Furthermore, for absolute clarity and the avoidance of doubt, I
      believe this guiding principle can be enshrined on the following
      single sentence:</p><p class="">&nbsp;&nbsp;&nbsp; "We cannot remove features from a static class that would
      otherwise be present in a standard class."</p><p class="">I believe following this principle we will arrive at the best
      implementation of static classes</p></div></div></blockquote><div><br class=""></div>A great principle, yes, but needing a small caveat:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>&nbsp;"...excepting features that by-nature are not relevant to the static class use-case, such as instance-based magic methods like `__get()`, `__set()`` and `__construct()`."</div></blockquote><div><br class=""></div><div>That might have been implied, but good to make it explicit.</div><div><br class=""></div><div>-Mike</div><br class=""></body></html>
--Apple-Mail=_B0F69558-DCDD-43EE-9A56-6EF15D045034--