- 1
if (substr(json_encode($row['list']), 0, 1) == '[') {
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+166
if (substr(json_encode($row['list']), 0, 1) == '[') {
Такой вот аналог is_array()
Проверять это через json_encode() всё-таки можно назвать убийством котят...
так не лучше ?
Странноватая схема, честно говоря, почему не могли договориться чтоб всегда было вложение с {"*":[123,456]} если не различаются... Но это не ко мне вопрос. :)
А эта схема еще странна тем, что непонятно, что делать если нужная локаль не нашлась. Юзать en_US? Юзать первую попавшуюся в массиве?
P.S. Я всё-таки за схему 1 файл - 1 язык. Она и работает пошустрее, т.к. не надо парсить кучу ненужных в данный момент языков (для пыхи, имхо, актуально). И новые переводы добавлять легко. Единственный минус - нужна тулза для редактирования, которая показывает, какие строки еще забыли перевести. Но без такой тулзы работа переводчика один хрен мазохизм ;)
Вот интересно, у этой софтины какая-то централизованная база, с которой работают переводчики, а файл - просто выгрузка из нее. Или же у них там веселый групповой секс с одним файлом? :) Во втором случае я им не завидую...
Эээ, а вот это тогда что? http://php.net/manual/ru/function.is-array.php
P.S. А тьфу, дошло, тут нужно именно отличить массив с циферками от ассоциативного массива... Но нахрена?!
Ох ё.
Но более точная проверка с is_string нужна ИМХО ещё реже, чем проверка на ассоциативность в принципе. :)
Если быть точнее, то из 2 раз на моём опыте ещё не было такого, чтоб array_values($arr) === $arr не подошёл.
У поиска только скан (причем при поиске первого - не до конца) и банальный and на слиянии. У фильтра - скан + копирование найденных (т.е. еще и выделение памяти) + слияние результатов в конце. В итоге у поиска меньше бесполезной для данного случая работы.
При проверке условия, аля "один из элементов is_string" или "все элементы is_string", тредам достаточно вернуть bool, а результаты объединить and'ом (или or'ом).
При поиске первого или любого элемента надо вернуть только один элемент из каждого треда.
Ну неужели эти два варианта не будут быстрее, чем полноценный фильтр, у которого каждый тред должен вернуть массив\список, а потом их еще и нужно объединить? :)
Как бы предположение такое, что мы создаем столько же тредов / процессов, сколько элементов есть в массиве :) Предположительно треды у нас очень дешевые, так что стоимостью создания можно пренебречь.
> Как бы предположение такое, что мы создаем столько же тредов / процессов, сколько элементов есть в массиве :) Предположительно треды у нас очень дешевые, так что стоимостью создания можно пренебречь.
Представим коня в виде материальной точки, котрая равномерно и прямолинейно движется в вакууме.
Ну т.е. это что-то близкое к тем же spark'ам в хаскеле, нежели к традиционному разбиению на крупные подзадачи и исполнению их в worker thread?
return true;