Re: Deprecating uniqid()

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