Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:126167
Precedence: bulk
MIME-Version: 1.0
References: <CAEKnhAEFJKPWWL0EKu_JBPgwBEe+Pk3GDzR7HQm3J-g7=Wk0BA@mail.gmail.com>
 <7228b901-a6a9-4aa9-8425-5ad51f66a853@gmx.de>
In-Reply-To: <7228b901-a6a9-4aa9-8425-5ad51f66a853@gmx.de>
Date: Sun, 22 Dec 2024 16:23:09 +0100
Message-ID: <CAEKnhAHx50FeHw=jpG7=2KmCGGn3CaP491dd6Lti3bxSAw0G1g@mail.gmail.com>
Subject: Re: [PHP-DEV] C Unit testing and mocking
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals list <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000cc4c560629dd7587"
From: bukka@php.net (Jakub Zelenka)

--000000000000cc4c560629dd7587
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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

--000000000000cc4c560629dd7587
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Dec 16, 2024 at 9:05=E2=80=AFPM C=
hristoph M. Becker &lt;<a href=3D"mailto:cmbecker69@gmx.de">cmbecker69@gmx.=
de</a>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex">On 16.12.2024 at 14:18, Jaku=
b Zelenka wrote:<br>&gt; There was a suggestion of RFC but that might be a =
bit too much as it&#39;s just<br>
&gt; an internal change / addition. But certainly some overview on internal=
s<br>
&gt; should be done so writing this instead.<br>
<br>
I&#39;m fine with not going through the RFC process, although the policy[1]=
<br>
police might come after us. :)<br>
<br></blockquote><div><br></div><div>I think it fits to all inclusion crite=
ria and doesn&#39;t go against any exclusion. Maybe except that &quot;de fa=
cto standard&quot; but for our use there was really no other option as I me=
ntioned in my comparison so it was the only library left for our needs if t=
here is only one, then it&#39;s &quot;de facto standard&quot; we could say.=
</div><div><br></div><div>Btw. It was probably mistake to set that policy f=
or C code because we don&#39;t really need to care if PHP recommends any to=
ol there - I completely missed it when voting for it. This should be just f=
or PHP application that we care about. We should modify that policy accordi=
ngly - I need to make a list of changes that to the policies as there are q=
uite a few points.</div><div><br></div><div>Regards,</div><div><br></div><d=
iv>Jakub</div></div></div>

--000000000000cc4c560629dd7587--