Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:110071
User-Agent: Cyrus-JMAP/3.3.0-dev0-413-g750b809-fmstable-20200507v1
Mime-Version: 1.0
Message-ID: <f07e2326-ec39-47d4-aed8-043b85005f24@www.fastmail.com>
In-Reply-To: 
 <CA+kxMuQ6Gaua-Ozk21KT2p8GWRhbkiQFZwYi+L22n5xq7S2ggQ@mail.gmail.com>
References: <9e3b1604-8d0a-9db4-aab6-e5f2198252f4@allenjb.me.uk>
 <C4580849-BC5B-45CA-9B57-56CB63B3F8F0@benramsey.com>
 <3a2924d2-31b9-fee5-5548-49c889eca2f4@heigl.org>
 <CALKiJKoXfW2usFmHS2ev2ihe6i=SV5JQaMgQmHCi5-rqeEdOWw@mail.gmail.com>
 <CANUQDCi3+fzy9E9kJ-vuDsTXMwNko9PpBUBAGUTxacdaQFPE5g@mail.gmail.com>
 <CAJvSBVMGEyqKNOxtGLyVqKrc0YRpiTyc8Ok55cocSS-2trL=Xw@mail.gmail.com>
 <CALKiJKpTf3AyhLjbMOu+gO--gmgatZ0Nazbsj2AZ-L2PVvOe5w@mail.gmail.com>
 <CAL0xaBG-VLN6pMPoKttkCZLXdzOKJLo0mdZvL2ggOy1Fqjae8w@mail.gmail.com>
 <D21D4456-228B-4059-9B51-F40B3EC94286@gmail.com>
 <CA+kxMuS5DcHd18Nq5eXCOZB24KUsydtq4tg+wXgTuPORO+XMrA@mail.gmail.com>
 <CALKiJKqwNXgYY3rc+wZqnuwtcq+WmAe8VjUvcuY1sFAvAJrEAQ@mail.gmail.com>
 <CA+kxMuQ6Gaua-Ozk21KT2p8GWRhbkiQFZwYi+L22n5xq7S2ggQ@mail.gmail.com>
Date: Thu, 07 May 2020 10:24:23 -0500
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain
Subject: Re: [PHP-DEV] Deprecating uniqid()
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, May 7, 2020, at 9:33 AM, Dan Ackroyd wrote:
> On Thu, 7 May 2020 at 10:13, Rowan Tommins <rowan.collins@gmail.com> wrote:
> >
> > Unless we're actively trying to shrink the functionality of PHP's core,
> 
> I think we should.
> 
> There are things that were added to core rather than done in userland because:
> 
> * distributing libraries in userland used to be a lot harder than it is now.
> 
> * Some stuff needed to be in core to give adequate performance. As
> userland PHP has had it's relative performance increased, and also
> computers have gotten a little faster since the project began*, that
> need has been greatly reduced.
> 
> So although the choice to provide some functionality in core was the
> correct choice at the time, it would not be a correct choice to do
> now.
> 
> The reason to try to reduce the amount of core code is that
> maintaining core code is much more difficult than maintaining userland
> libraries.
> 
> There are swathes of PHP core that are scary to fix bugs in, let alone
> think about adding new features or refactoring their API.
> 
> Although each removal would need to be justified individually, I think
> as a general aim 'more userland, less core' is good.
> 
> cheers
> Dan
> Ack
> 
> * 
> https://github.com/php/php-src/blob/cdade2e35da528608e777d2f9766253726edb36c/ext/opcache/zend_accelerator_hash.c#L27

 Between preloading, PHP 7's improvements, FFI funkiness, and the upcoming JIT, there's been on and off discussion about moving much of the standard library from C to "PHP code that is bundled and preloaded automatically."  A real "standard library" in PHP, rather than a bunch of bridged C functions that exist for the legacy reasons Dan notes above.

Making that actually a thing would help obviate a lot of these issues, I think.  It becomes no longer an implementation question but "just" a packaging question.

--Larry Garfield