Hello Ben, On Thu, 7 May 2020 at 17:29, Ben Ramsey <b...@benramsey.com> wrote:
> > On May 7, 2020, at 09:33, Dan Ackroyd <dan...@basereality.com> wrote: > > *snip* > > I’m done waxing philosophical, so what I can say about `uniqid()`? > > This is one of those functions I think (without doing the research) is > used a lot in CLI scripts and tooling. As a result, it may be impossible to > do good research on this, since these scripts are probably not available in > public repositories. Additionally, when I write scripts like this, I don’t > reach out for Composer packages, since I don’t need the overhead of a > full-blown project or library, and I doubt others do, as well. This means > allowing userland to fill the void left by the removal of `uniqid()` may > not be a good option. > I think we should err on the side of BC with `uniqid()`. While the manual > says it’s been in the language since PHP 4, the research I did in the > “museum” shows that it’s been in PHP since 2.0b9 (see the Changelog in the > tarball for 2.0b10[6]). > > Is there any way we can improve this function without deprecating/removing > it? > Exactly my case - a background processing script that lives in CLI without any 3rd party libraries parsing a CSV just doing some SQL queries inserting data and using uniqid(more_entropy=true) (and removing the dot from it's output). In my opinion, this is one of those somewhat simple and widely used functions that do not need constant updating and just making it's random part more robust and up to date will be sufficient for it's use. Yes, we can depreciate the uniqid and replace it with a new function that is much better at its job to facilitate proper migration. But removing a tool like this from the core does seem somewhat on the extreme end of things. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
