Re: [RFC] Make uniqid() more unique

2016-09-09 11:07 GMT+03:00 Yasuo Ohgaki <yohgaki@ohgaki.net>: > On Fri, Sep 9, 2016 at 4:40 PM, Niklas Keller <me@kelunik.com> wrote: > > I think it's better to leave it as is and deprecate and discourage its > use. > > There's already a big warning there. Dunno whether there are really valid > > use cases for it. > > uniqid() is handy, when developer would like to sort something by > "time" prefix/postfix in strings. For example, prefixed/postfixed > session ID by "time". > > So E_DEPRECATE might be too much. > > Regards, > > -- > Yasuo Ohgaki > yohgaki@ohgaki.net > It's also useful in other cases, where using a full blown true random source is just overkill. For example, my recent usage was to use the result of uniqid('', true) as a few parameters in URL's instead of plain numeric ID. Client just wanted to users can't do a +1 and see someone else's result page that might have a different text or a different campaign even. And I do need to generate those id's in bursts - 200 to 600 id's in a single action, I would imagine generating 600 random strings of ~20 char length can be hard on the source of the randomness, may even deplete it. And I expect the numbers to grow. So, deprecating it I think is really an overreaction. It's a handy tool. It can be used to generate filenames too, and a lot of other stuff. My thoughts are - improve it. Yes, the standard uniqid() is a bit too short, I have never used it without the second "true" parameter and that dot in the middle of the string is annoying - I had to strip it out every use case I had. Arvids.