Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126178
Precedence: bulk
MIME-Version: 1.0
References: <CAEKnhAEFJKPWWL0EKu_JBPgwBEe+Pk3GDzR7HQm3J-g7=Wk0BA@mail.gmail.com>
 <7228b901-a6a9-4aa9-8425-5ad51f66a853@gmx.de> <CAEKnhAHx50FeHw=jpG7=2KmCGGn3CaP491dd6Lti3bxSAw0G1g@mail.gmail.com>
 <2556faa6-c233-4809-8999-afe1af40f4f1@app.fastmail.com>
In-Reply-To: <2556faa6-c233-4809-8999-afe1af40f4f1@app.fastmail.com>
Date: Thu, 26 Dec 2024 13:25:48 +0100
Message-ID: <CAEKnhAFMw9h4oxLbze9eQH2q06OabEOuUc7uetoLGJrBmuygAg@mail.gmail.com>
Subject: Re: [PHP-DEV] C Unit testing and mocking
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000dde91e062a2b726b"
From: bukka@php.net (Jakub Zelenka)

--000000000000dde91e062a2b726b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, Dec 24, 2024 at 8:40=E2=80=AFPM Larry Garfield <larry@garfieldtech.=
com>
wrote:

> On Sun, Dec 22, 2024, at 9:23 AM, Jakub Zelenka wrote:
> > On Mon, Dec 16, 2024 at 9:05=E2=80=AFPM Christoph M. Becker <cmbecker69=
@gmx.de>
> wrote:
> >> On 16.12.2024 at 14:18, Jakub Zelenka wrote:
> >> > There was a suggestion of RFC but that might be a bit too much as
> it's just
> >> > an internal change / addition. But certainly some overview on
> internals
> >> > should be done so writing this instead.
> >>
> >> I'm fine with not going through the RFC process, although the policy[1=
]
> >> police might come after us. :)
> >>
> >
> > I think it fits to all inclusion criteria and doesn't go against any
> > exclusion. Maybe except that "de facto standard" but for our use there
> > was really no other option as I mentioned in my comparison so it was
> > the only library left for our needs if there is only one, then it's "de
> > facto standard" we could say.
> >
> > Btw. It was probably mistake to set that policy for C code because we
> > don't really need to care if PHP recommends any tool there - I
> > completely missed it when voting for it. This should be just for PHP
> > application that we care about. We should modify that policy
> > accordingly - I need to make a list of changes that to the policies as
> > there are quite a few points.
> >
> > Regards,
> >
> > Jakub
>
> Point of order: The recently adopted 3rd party code policy does not apply
> to C tooling.  It mentions "PHP Tooling", which is defined as "PHP code r=
un
> by PHP.net".  The website, docs tooling, etc.  It has no bearing on what =
C
> libraries or toolchains can or should be used in php-src itself.  (Whethe=
r
> that's unit testing, url parsers, HTML parsers, threading libraries, etc.=
)
>
>
Ah ok, thanks for the clarification. This part (Definitions -> Librarires)
is slightly confusing in this regard though:

> Refers to existing third party code packages or tools, either C
extensions or PHP code, maintained by someone other than the PHP Internals
team.

Specifically that C extensions part made it sound like it also applies to C
code. But after reading the introduction, it's probably more as you say,
and it applies only to PHP code.

Cheers

Jakub

--000000000000dde91e062a2b726b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Dec 24,=
 2024 at 8:40=E2=80=AFPM Larry Garfield &lt;<a href=3D"mailto:larry@garfiel=
dtech.com">larry@garfieldtech.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">On Sun, Dec 22, 2024, at 9:23 AM, Jakub Ze=
lenka wrote:<br>
&gt; On Mon, Dec 16, 2024 at 9:05=E2=80=AFPM Christoph M. Becker &lt;<a hre=
f=3D"mailto:cmbecker69@gmx.de" target=3D"_blank">cmbecker69@gmx.de</a>&gt; =
wrote:<br>
&gt;&gt; On 16.12.2024 at 14:18, Jakub Zelenka wrote:<br>
&gt;&gt; &gt; There was a suggestion of RFC but that might be a bit too muc=
h as it&#39;s just<br>
&gt;&gt; &gt; an internal change / addition. But certainly some overview on=
 internals<br>
&gt;&gt; &gt; should be done so writing this instead.<br>
&gt;&gt; <br>
&gt;&gt; I&#39;m fine with not going through the RFC process, although the =
policy[1]<br>
&gt;&gt; police might come after us. :)<br>
&gt;&gt; <br>
&gt;<br>
&gt; I think it fits to all inclusion criteria and doesn&#39;t go against a=
ny <br>
&gt; exclusion. Maybe except that &quot;de facto standard&quot; but for our=
 use there <br>
&gt; was really no other option as I mentioned in my comparison so it was <=
br>
&gt; the only library left for our needs if there is only one, then it&#39;=
s &quot;de <br>
&gt; facto standard&quot; we could say.<br>
&gt;<br>
&gt; Btw. It was probably mistake to set that policy for C code because we =
<br>
&gt; don&#39;t really need to care if PHP recommends any tool there - I <br=
>
&gt; completely missed it when voting for it. This should be just for PHP <=
br>
&gt; application that we care about. We should modify that policy <br>
&gt; accordingly - I need to make a list of changes that to the policies as=
 <br>
&gt; there are quite a few points.<br>
&gt;<br>
&gt; Regards,<br>
&gt;<br>
&gt; Jakub<br>
<br>
Point of order: The recently adopted 3rd party code policy does not apply t=
o C tooling.=C2=A0 It mentions &quot;PHP Tooling&quot;, which is defined as=
 &quot;PHP code run by PHP.net&quot;.=C2=A0 The website, docs tooling, etc.=
=C2=A0 It has no bearing on what C libraries or toolchains can or should be=
 used in php-src itself.=C2=A0 (Whether that&#39;s unit testing, url parser=
s, HTML parsers, threading libraries, etc.)<br><br></blockquote><div><br></=
div><div>Ah ok, thanks for the clarification. This part (Definitions -&gt; =
Librarires) is slightly confusing in this regard though:<br><br>&gt;=C2=A0R=
efers to existing third party code packages or tools, either C extensions o=
r PHP code, maintained by someone other than the PHP Internals team.</div><=
div><br></div><div>Specifically that C extensions part made it sound like i=
t also applies to C code. But after reading the introduction, it&#39;s prob=
ably more as you say, and it applies only to PHP code.</div><div><br></div>=
<div>Cheers</div><div><br></div><div>Jakub</div></div></div>

--000000000000dde91e062a2b726b--