On Tue, 10 Sept 2024, 22:49 Gina P. Banyard, <intern...@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 >
