Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123875
Precedence: bulk
MIME-Version: 1.0
References: <eb3f59cc-3ed8-461a-a3a4-f6ba10ed31e1@scriptfusion.com>
 <ef0c3617-6757-45a1-a485-3f7c197fd599@app.fastmail.com> <4596aa73-cfd4-2292-7191-2839a5bab695@php.net>
In-Reply-To: <4596aa73-cfd4-2292-7191-2839a5bab695@php.net>
Date: Wed, 26 Jun 2024 12:05:09 -0600
Message-ID: <CAM7F2--zTgD7ar7cXcX9xXf=5ZdLpz0tSVqUns1COonUKbZg9Q@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] Static class
To: Derick Rethans <derick@php.net>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000064c5f3061bcedbe2"
From: lnearwaju@gmail.com (Lanre)

--00000000000064c5f3061bcedbe2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

In JavaScript/Typescript, we can declare functions that are local to the
current file by not exporting them. In C/C++ this is achieved by simply
writing the function in the implementation file as opposed to the header.
However, achieving a similar level of privacy in PHP requires using private
static methods, or else you incur the overhead of creating an object for
stateless functions. How do you propose handling such cases using
namespaced functions? Can you think of any scenarios where hiding non-API
functions might be necessary? I'm curious why you keep returning to
namespaced functions when they don't fulfill the same role.

Cheers,
Lanre
On Tue, Jun 25, 2024 at 9:20=E2=80=AFAM Derick Rethans <derick@php.net> wro=
te:

> On Sun, 23 Jun 2024, Larry Garfield wrote:
>
> > On Sun, Jun 23, 2024, at 6:10 PM, Bilge wrote:
> > > Hi Internals!
> > >
> > > I am pleased to present my first RFC: Static class
> > > <https://wiki.php.net/rfc/static_class>.
> > >
> > > This work is based on the previous discussion thread on this list of
> the
> > > same name, and hopefully captured all the relevant details,
> > > notwithstanding anything unanticipated that may present itself during
> > > the implementation. Let me know if you feel anything important has
> been
> > > missed. I am aware it omits to mention specifics about messages so
> > > emitted when runtime or compile-time errors occur, but I anticipate
> this
> > > can be hashed out in the PR, unless consensus indicates otherwise.
> > >
> > > I am aware this idea is not supported by everyone, but there seemed t=
o
> > > be enough positive voices for it to be worth a shot. I'd like to get =
a
> > > better idea of where people might stand when it comes down to a vote,
> > > now there is a formal RFC, so we know whether it's worth completing
> the
> > > implementation, although any sentiments so proffered are of course no=
t
> a
> > > commitment to vote any particular way and nobody should feel compelle=
d
> > > to speak to that unless comfortable. Looking forward to feedback!
>
> <snip>
> >
> > For the record, as previously stated, I will be voting No on this RFC.
>
> Having read this thread, and the previous one from half a year ago, I
> will do so too. In short, we shouldn't be encouraging static classes as
> a bag of static functions, that ought to be just namespaced functions.
>
> cheers,
> Derick
>

--00000000000064c5f3061bcedbe2
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>In JavaScript/Typescript, we can declare functions th=
at are local to the current file by not exporting them. In C/C++ this is ac=
hieved by simply writing the function in the implementation file as opposed=
 to the header. However, achieving a similar level of privacy in PHP requir=
es using private static methods, or else you incur the overhead of creating=
 an object for stateless functions. How do you propose handling such cases =
using namespaced functions? Can you think of any scenarios where hiding non=
-API functions might be necessary? I&#39;m curious why you keep returning t=
o namespaced functions when they don&#39;t fulfill the same role.</div><div=
><br></div><div>Cheers,</div><div>Lanre</div><div class=3D"gmail_quote"><di=
v dir=3D"ltr" class=3D"gmail_attr">On Tue, Jun 25, 2024 at 9:20=E2=80=AFAM =
Derick Rethans &lt;<a href=3D"mailto:derick@php.net">derick@php.net</a>&gt;=
 wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, =
23 Jun 2024, Larry Garfield wrote:<br>
<br>
&gt; On Sun, Jun 23, 2024, at 6:10 PM, Bilge wrote:<br>
&gt; &gt; Hi Internals!<br>
&gt; &gt;<br>
&gt; &gt; I am pleased to present my first RFC: Static class <br>
&gt; &gt; &lt;<a href=3D"https://wiki.php.net/rfc/static_class" rel=3D"nore=
ferrer" target=3D"_blank">https://wiki.php.net/rfc/static_class</a>&gt;.<br=
>
&gt; &gt;<br>
&gt; &gt; This work is based on the previous discussion thread on this list=
 of the <br>
&gt; &gt; same name, and hopefully captured all the relevant details, <br>
&gt; &gt; notwithstanding anything unanticipated that may present itself du=
ring <br>
&gt; &gt; the implementation. Let me know if you feel anything important ha=
s been <br>
&gt; &gt; missed. I am aware it omits to mention specifics about messages s=
o <br>
&gt; &gt; emitted when runtime or compile-time errors occur, but I anticipa=
te this <br>
&gt; &gt; can be hashed out in the PR, unless consensus indicates otherwise=
.<br>
&gt; &gt;<br>
&gt; &gt; I am aware this idea is not supported by everyone, but there seem=
ed to <br>
&gt; &gt; be enough positive voices for it to be worth a shot. I&#39;d like=
 to get a <br>
&gt; &gt; better idea of where people might stand when it comes down to a v=
ote, <br>
&gt; &gt; now there is a formal RFC, so we know whether it&#39;s worth comp=
leting the <br>
&gt; &gt; implementation, although any sentiments so proffered are of cours=
e not a <br>
&gt; &gt; commitment to vote any particular way and nobody should feel comp=
elled <br>
&gt; &gt; to speak to that unless comfortable. Looking forward to feedback!=
<br>
<br>
&lt;snip&gt;<br>
&gt; <br>
&gt; For the record, as previously stated, I will be voting No on this RFC.=
<br>
<br>
Having read this thread, and the previous one from half a year ago, I <br>
will do so too. In short, we shouldn&#39;t be encouraging static classes as=
 <br>
a bag of static functions, that ought to be just namespaced functions.<br>
<br>
cheers,<br>
Derick<br>
</blockquote></div></div>

--00000000000064c5f3061bcedbe2--