Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125495
Precedence: bulk
MIME-Version: 1.0
References: <9791621c-1313-4306-bc6a-5dd789f2b2df@gmx.de> <51FA7D6F-09F6-4267-9B57-5CBD42EA898C@cmpct.info>
 <57156bdd-cf93-404f-a10c-cd842bd7bb92@app.fastmail.com> <27cbee89-093f-4903-baec-a10058370c33@gmx.de>
 <Vk6SQnh3n0wWFW8G1Sop-c8QaZEZSbYfWa106Qax1FSiw3dRPzf4xRPu-I-v2HtpGvsFy-3X2x7pmMUzPpnhL_l7cLZ612ApF53Q0Bd50Xw=@gpb.moe>
In-Reply-To: <Vk6SQnh3n0wWFW8G1Sop-c8QaZEZSbYfWa106Qax1FSiw3dRPzf4xRPu-I-v2HtpGvsFy-3X2x7pmMUzPpnhL_l7cLZ612ApF53Q0Bd50Xw=@gpb.moe>
Date: Tue, 10 Sep 2024 23:09:44 +0200
Message-ID: <CANNiG7hVptQWN__WksSRtxAbyYo1rjMRs1=vm0rh0Db2HNxaDQ@mail.gmail.com>
Subject: Re: [PHP-DEV] What to do with ext/snmp?
To: "Gina P. Banyard" <internals@gpb.moe>
Cc: "Christoph M. Becker" <cmbecker69@gmx.de>, Jim Winstead <jimw@trainedmonkey.com>, 
	PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ad6c320621ca4bad"
From: bilge@scriptfusion.com (Bilge)

--000000000000ad6c320621ca4bad
Content-Type: text/plain; charset="UTF-8"

On Tue, 10 Sept 2024, 22:49 Gina P. Banyard, <internals@gpb.moe> wrote:

>
> But it is my biggest belief that most extensions would be better outside
> the php-src repo and live in PECL so they could be updated independently
> and not tied to the yearly PHP release schedule.
> The fact that ext/cURL is not allowed to be updated in patch releases any
> more means that features in libcurl take *ageees* to get exposed in PHP.
> It also prevents extensions to be properly refactored because they are
> bound to the same BC policy as the PHP engine, which doesn't make a lot of
> sense to me.
> I could have cleaned-up ext/xml with all the weird "string method
> callables" used with xml_set_object() in 1 week by releasing 3 different
> versions on PECL, instead of performing some refactoring and 1 RFCs. [1]
> Or fix ext/dba and do a release without the absurd parameter type of
> dba_key_split().
> Having the DOM extension in PECL and be able to just change the behaviour
> of the legacy classes to fix them instead of creating a whole new hierarchy
> which slows down adoption could also have been prevented (if it is a good
> idea) if it wasn't tied to PHP's release schedule and BC policy.
> It would also permit extensions to follow semver while the engine
> continues to have its own versioning system.
>

I really look forward to this. It will be a brave new world when PHP can
ship without (m)any extensions and PIE can be used by anyone to customise
what's loaded. Only then will the power of PHP's (existing) modularity be
fully appreciated.

Cheers,
Bilge

>

--000000000000ad6c320621ca4bad
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Tue, 10 Sept 2024, 22:49 Gina P. Banyard, &lt;inter=
nals@gpb.moe&gt; wrote:=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But it is my biggest belief that most extensions would be better outside th=
e php-src repo and live in PECL so they could be updated independently and =
not tied to the yearly PHP release schedule.<br>
The fact that ext/cURL is not allowed to be updated in patch releases any m=
ore means that features in libcurl take *ageees* to get exposed in PHP.<br>
It also prevents extensions to be properly refactored because they are boun=
d to the same BC policy as the PHP engine, which doesn&#39;t make a lot of =
sense to me.<br>
I could have cleaned-up ext/xml with all the weird &quot;string method call=
ables&quot; used with xml_set_object() in 1 week by releasing 3 different v=
ersions on PECL, instead of performing some refactoring and 1 RFCs. [1]<br>
Or fix ext/dba and do a release without the absurd parameter type of dba_ke=
y_split().<br>
Having the DOM extension in PECL and be able to just change the behaviour o=
f the legacy classes to fix them instead of creating a whole new hierarchy =
which slows down adoption could also have been prevented (if it is a good i=
dea) if it wasn&#39;t tied to PHP&#39;s release schedule and BC policy.<br>
It would also permit extensions to follow semver while the engine continues=
 to have its own versioning system.<br></blockquote></div></div><div dir=3D=
"auto"><br></div><div dir=3D"auto">I really look forward to this. It will b=
e a brave new world when PHP can ship without (m)any extensions and PIE can=
 be used by anyone to customise what&#39;s loaded. Only then will the power=
 of PHP&#39;s (existing) modularity be fully appreciated.=C2=A0</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto">Cheers,</div><div dir=3D"auto">Bilg=
e=C2=A0</div><div dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"></blockquote></div></div></div>

--000000000000ad6c320621ca4bad--