Что-то более случайное чем random_bytes()?

она не гарантирует уникальность

Ну да, про уникальность понял, можно время примешать, но всё равно гарантии не будет. Хотя наверное вероятность совпадения будет ничтожно малой.

да, это так проблема из пальца)

потому что у тебя изначальный вариант вполне нормальный и понятный)

имхо

вот так посмотри http://pastebin.com/tztdfQX2

Не понял преимущества твоего способа, ведь в нём минусом будет дальнейшее расширение метода. Если захочу что-то добавить и вместо одной строки придётся две делать и больше.

что именно захочешь добавить ? в setUid

он именно говорит что он проставляет значение в setUid и все хватит, остальное свои методы

можно даже внутри setUid проверять уникальность и валидировать)

я не говорю что оно лучше

Ну вот чтобы прям 100% уникальность была (ну или 99,(9)) то мне нужно будет время туда примешать, хэш его, хэши сконкатенировать и т.д.

неа

можно нафигарить что то типо этого

вот так можно сделать )) http://pastebin.com/2ZFc8n0Z

но на самом деле это плохо )

:D

и уникальность науровне процесса

можно проверять в бд и тд)))

что тоже не плохо

Нет, все объекты независимы и проверять негде их уникальность, она должна быть "гарантированной". Хоть и в кавычках. ?

насколько важна случайность uid ?

сделай авто инкремент

я бог костылей :D

Нет, тогда перебор возможен. Это внешний доступ будет. Да ладно, я ещё сам думаю над реализацией. А вас тут путаю, не выложив всех условий.

Ну это не костыль в определённых случаях. ?

если критична уникальность и важна случайность то надо хранить прошлые варианты и проверять не было ли их раньше

если уникальность не настолько важна и можно использовать алгоритмы которые с редкой веростностью дают энтропию)

Думаю что это будет уникально: $this->uid = hash('md5', microtime(true)) . bin2hex(random_bytes(16)); Даже если время будет одинаковое (при синхронизации оно повторится), вероятность того, что в одну микросекунду сгенерируется такая же случайная строка, ничтожно мала.

hash('md5', microtime(true)) обладает энтропией тут может быть не одна секунда)

:D

микросекунда0

:D

? ну это уже фантастика.

колизия )

ну это математика)))

она жестока)

Я в курсе, но вероятность ничтожна.

а тут все идеалисты)

на самом деле я уже говорил и первый вариант достаточен)))

Я в курсе, но вероятность ничтожна.

открыть 2 keepalive соединения на сервере с пингом <1ms и отправить 2 запрос

version_compare для >= 7.0.0 bin2hex(random_bytes(32)); для остальных либо bin2hex(mcrypt_create_iv(32,PARAM) или bin2hex(openssl_random_pseudo_bytes

или /dev/urandom

:D

открыть 2 keepalive соединения на сервере с пингом <1ms и отправить 2 запрос

Так мы же говорим про сочетание двух частей. Вторая генерирует криптографически случайные байты. И вероятность совпадения ничтожна. А то что хэш времени может повториться - да, при синхронизации например, т.е. когда время снова будет таким же.

Ну или при одновременных запросах.

Так мы же говорим про сочетание двух частей. Вторая генерирует криптографически случайные байты. И вероятность совпадения ничтожна. А то что хэш времени может повториться - да, при синхронизации например, т.е. когда время снова будет таким же.

если одна уже генерирует криптографически случайные байты, то вторая часть становится совершенно бесполезной

Вообще согласен. ?

В общем вернулись к началу.

случайные != уникальные

$this->setUID(bin2hex(random_bytes(16)));

Нет, они именно уникальные будут.

Из-за их количества. И вероятности повториться.

случайные != уникальные

уникальные != случайные

там, на днях, дядько боб будет вещать про tdd и котлин, кому-то интересно?

uuid для слабаков?

uuid для слабаков?

Она не случайна.

продолжи мысль

на вики

https://habrahabr.ru/post/135364/ вот и на хабре

Она не случайна.

Version 4 UUIDs are generated using random or pseudo-random numbers.

uuid не гарантирует отсутствие коллизии

зависит от реализации

uuid он случаен, но не гарантирует что не будет колизии

для исключения колизии нужна центральная точка, которая скажет есть такое или нет, а еще лучше скажет, какой id юзать

но там вроде изанчально такой задачи нет

то, что здесь обсуждалось

ERROR: S client not available

на ровном месте к коду который в 99% работает

и придумали проблему

а?

мы тут вроде решили проблему

там, на днях, дядько боб будет вещать про tdd и котлин, кому-то интересно?

конечно)

конечно)

https://twitter.com/intellijidea/status/817008962239426560

Warning: The webinar is full.

будем ждать онлайн(

uuid он случаен, но не гарантирует что не будет колизии

какова вероятность коллизии?

уверен, что достаточно маленькая, чтобы об этом не думать

уверен, что достаточно маленькая, чтобы об этом не думать

на вики написано)

зависит от объема данных, доводилось сталкиватся с наступлением этой самой ситуации

но это было на старой работе и сейчас пофиг)

Запись с rsdn: "Экономить их надо! А то все, кому не лень, генерируют и генерируют, не напасешься! Опомнитесь! Мировой запас UUID’ов ограничен! Подумайте об экологии в следующий раз, как рука потянется к кнопке «Сгенерировать»! И обязательно отдавайте старые ненужные UUID’ы на утилизацию. Что мы оставим потомкам-то? " ?

это старинный текст кажется, "Ecology of GUID"

Ive heard similar things being said about curly braces

And semicolons

well, GUIDs are clearly a limited resource while semicolons are not

Like bitcoins huh

:)

Where can i find GUID exchange?

Запись с rsdn: "Экономить их надо! А то все, кому не лень, генерируют и генерируют, не напасешься! Опомнитесь! Мировой запас UUID’ов ограничен! Подумайте об экологии в следующий раз, как рука потянется к кнопке «Сгенерировать»! И обязательно отдавайте старые ненужные UUID’ы на утилизацию. Что мы оставим потомкам-то? " ?

ахаха

Господа, вот скажите, как правильно принято назыать интерфесы? Сейчас по пыхе: Есть у меня несколько классов-сервисов, которые могут срать ошибками. С их названием проблем нет. Есть Интерфейс для них, который хз как правильно обозвать. Есть трейт HasErrors, название которого тоже с натяжкой подходит, ибо слова Errorable не существует. Короче, беда у меня с именованием. Может кто подскажет какие-то общие принципы как и что обзывать, чтоб понятно было потом понятно каждому склонному к насилию психопату

Господа, вот скажите, как правильно принято назыать интерфесы? Сейчас по пыхе: Есть у меня несколько классов-сервисов, которые могут срать ошибками. С их названием проблем нет. Есть Интерфейс для них, который хз как правильно обозвать. Есть трейт HasErrors, название которого тоже с натяжкой подходит, ибо слова Errorable не существует. Короче, беда у меня с именованием. Может кто подскажет какие-то общие принципы как и что обзывать, чтоб понятно было потом понятно каждому склонному к насилию психопату

А интерфейсы для ошибок в принципе нужны?

Господа, вот скажите, как правильно принято назыать интерфесы? Сейчас по пыхе: Есть у меня несколько классов-сервисов, которые могут срать ошибками. С их названием проблем нет. Есть Интерфейс для них, который хз как правильно обозвать. Есть трейт HasErrors, название которого тоже с натяжкой подходит, ибо слова Errorable не существует. Короче, беда у меня с именованием. Может кто подскажет какие-то общие принципы как и что обзывать, чтоб понятно было потом понятно каждому склонному к насилию психопату

для интерфейсов я бы использова ServiceInterface (или без префикса Interface)

для трейта я обычно названия NameTrait (с префиксом указываю, можно без)

но сейчас прибегут люди и докажут что это не правильно и надо все переписывать в DDD

замена Errorable меняется легко на hasError

и все что возвращает bool обычно с префиксом has в методах

А интерфейсы для ошибок в принципе нужны?

да хз. Для строгости пилю. Чтоб если возможны ошибки, то класс мог с ними работать и я в это был бы уверен

замена Errorable меняется легко на hasError

тут речь больше про именование самого трейта, а не метода, но я его так и назвал.

ну мол зачем ошибке интерфейс