Hi Pierre, On Thu, Oct 20, 2016 at 7:12 PM, Pierre Joye <pierre....@gmail.com> wrote: >> Application requires unique ID under across multi process/thread >> tasks, it will have more chance to have collided unique ID. > > uniqid fill(s|ed) some needs or maybe still fits for some. > > However for modern application with many concurrent requests or nodes, > it does not fit anymore, since long. Do we need to fix a broken hammer > to fix the screw? I do not think so. >
I'm all for bringing UUID to PHP by default, encourage users to use it for applications requires very unique ID. Let's have UUID module by default someday! > I suggested already to simply improve it if we can do it without > breaking BC and recommend to use something designed for such tasks, > UUID. ramsey/uuid is one of them, other are available. I'm aware of that entropy must be enabled by default, too. I guess you feel uniqid() improvement is impossible due to vote. You could be right about it. As far as I searched, there is no code have problem even when entropy on/off and additional chars/format. (Found one test script that tests uniqid(). Cannot tell if db has char(13) or like, though) We made rand() a alias of mt_rand(). IMHO, we are better not to leave _too_ weak unique ID generation function alone. HTML ID attribute and test data ID is common uniqid() use case. Let's make it reasonably unique for ID attributes, test database unique values, etc. Regards, P.S. If uniqid() is a "Shouldn't use function", we don't have to care little BC too much. Making it a "Can use function" for proper purposes is reasonable choice. I'm +1 for deprecating and removing uniqid(), but I presume it will never happen. That's why I'm trying to improve it. -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
