toxa82, не мелочи, как минимум это ограничения на использование подобного подхода (не получится "что угодно пихать"), когда знаешь эти особенности. А если не знаешь или забыл, то огромное поле для ошибок. Если бы неявные преобразования были бы мелочью, то никто бы не заморачивался типами в 7ке, благодаря чему php стал языком с нормальным контролем.
К примеру, "мелочи":
if (empty($arr[$id])) {
$arr[$id] = $id;
}
empty проводит сравнение с false с приведением типов, а значит существующие значения 0, '', false будут проходить проверку и это полностью нарушает логику.
if (!in_array($id, $arr)) {
$arr[] = $id;
}
здесь in_array опять же используется с приведением типов, а значит использование разных типов приведет к проблемам. А если говорит про версии до 8, то там будет вообще полный бред, in_array(1,['1q']) выдаст true.
Поэтому все это мелочи, пока не наткнетесь на ошибки, пораждаемые такими "мелочами".
toxa82, т.е. вы предлагаете значение элемента массива еще и в ключи класть? Да, конечно, при достаточно большом массиве, проверка 1 значения по ключу будет быстрее чем перебор всего массива. Но тут надо помнить, что ключи имеют свои особенности, к примеру, числа в строке будут преобразованы в числа.
эта функция медленнее чем проверка в массиве по ключу через isset или empty
in_array проверяет значения, какая связть с проверками по ключу? Если имелось ввиду перебирать весь массив по ключам, то очевидно, что это будет гораздо медленней, чем обход массива с помощью итератора.
Дистрибутив - это форма распространения ПО, для GNU Linux это некая сборка ядра и ОС для организации как минимум минимального набора для работы. Как это будет - зависит от вашей фантазии. Будет ли там установщик, будет ли там пакетный менеджер, будет ли он контролировать зависимости, все ваш выбор. Будет ли ядро в бинарниках или вы заставите пользователя собирать его из исходников, тоже ваш выбор.
mayton2019, Александр Талалаев, ага, сейчас современные тенденции - только строгая/сильная статическая типизация. И вот, программист например на ts расскажет, как всего у него строго. А программист использующий Си робко спросит, а как же операции, например с числами разной длины в байтах, неужели каждый раз вручную надо преобразовывать? Неа, ответит первый программист, мы сразу фигачем все в типы с максимальной длиной и не паримся, но зато у нас все строго и кошерно.
Не то, что бы я за многочисленные неявные преобразования, но все же, не все так однозначно.
Drno, если уж сравнивать, то максимальное кол-во ПО будет у Арча, т.к. там есть пользовательский репозиторий, в котором найти можно что угодно, и он ни в какое сравнение не идет с Debian по кол-ву софта. Дело в том, что там сборка настраивают из чего угодно, хоть из deb пакетов, хоть из исходников. Но, это пользовательский реп, со всеми присущими рисками, поэтому нужно проверять, что и откуда ставится в установочной инструкции.
res2001, да, примерно так, для сервера разумеется не Арч, об этом я и писал. Но выискивать какую-то лучшую стабильность в FreeBSD, в сравнении с Debian или CentO, точно не стоит. Про долгую сборку, это я писал про Генту, FreeBSD отдельный вопрос.
И да, Ubuntu вполне себе удобный рабочий инструмент.
Adamos, как и в другом дистрибутиве, ставишь из пакета, настраиваешь конфиг. Разница на уровне дистрибутива в большинстве случаев может быть только одна, с какими параметрами собирали ПО, а здесь cannonical вполне может и свое что-нибудь учудить.
Ubuntu уже давно не Debian даже внутри. Там настолько все перефигачено, что от Debain мало что осталось. Полностью своя сборка ядра, со своими патчами, причем их столько, что уже какой-то супермутант, а не ядро. Полностью свои сборки ПО, со своими багами, которых нет в Debian (например, баг в xrandr тянулся годами). Свои "странные" решения в инфраструктуре, типа bindDNS на все.
Не, разве что, пакетный менеджер исторически остался.
res2001, Arch не стабильный? Это с чего вы так решили? За последние годы, не видел проблем с ним. Ролинг релизы не отменяют тестирование и доставку проверенного ПО. Да, теоретически всегда есть шанс, что какой-то конфликт не будет выявлен заранее, поэтому это плохой вариант для сервера, но идеальный вариант для персонального использования. Потому что, если сравнить с тем же Debian, то стабильный релиз имеет очень старое ПО и это печально, нестабильный еще более нестабильный, чем Арч (про старый стабильный вообще молчу, там ПО, которое еще при мамонтах релизилось). Поэтому, одним из веселых развлечений в подобных дистрибутивах, это поиск нормального свежего ПО, бекпорты и прочие танцы с бубном, но в конце концов релиз протухает и его нужно обновлять, а никто не поручится, что после обновления он будет работать (и в 90% чтото докручивать все равно придется, а то и вообще не взлетит). Но про все это забываешь, как страшный сон, когда у тебя дистрибутив с роллинг релизами. Ты просто работаешь, а не занимаешься обслуживанием дистрибутива.
Мне подход гентушников совсем не понятен, собирать из исходников в 21 веке - это очень интересно для обучения, для работы абсолютно бесполезно. Все оптимизации подобного рода сейчас, это экономия на спичках. Получить абсолютно неощутимый прирост производительности и для этого неделями собирать систему - это развлечение, исследование, но не для пользователей.
FreeBSD очень кичится свой стабильностью, но на практике какой-нибудь CentOS будет чаще падать, чем FreeBSD? Нет, не будет. Зато GNU утилиты в CentOS на порядок удобнее, чем в FreeBSD (тупо синтаксис и функциональность у последних ограниченней).
Вообще стабильность системы не достигается стабильностью работы ОС. В 22 году на это никто не расчитывает, когда что-то сбойнет в железе, абсолютно не важно насколько стабильно ПО, поэтому стабильность всегда обеспечивается дублированием и резервированием.
CityCat4, серьезно, генту? Оно, конечно, забавно, но не для работы. Философия низкоуровневых настроек при сборке - это очень круто, но профита от этого практически нет в 22 году. Генту уже давно и пакеты стала использовать, т.к. просто не реально все собирать с нуля. Тем, не менее, сколько у вас уходит на то, чтобы пересобрать мир?
Речь ведь про функцию WP, а не PHP? Тогда поставьте соответствующий тег, чтобы отвечали по теме.
Неужели гугл не помог? Поверхностное гугление говорит мне, что нужно отвязать WP от хука, и перенаправить хук на новую функцию.
Соглашусь, что под разные вакансии нужно разное. Но, если посмотреть отвлеченно, то использовать или нет фреймворк зависит от задачи. Делать сайт и заново изобретать роутинг и прочее - очень странный подход. Но и тянуть в задачу фреймворк, если не используете 90% его функционала - тоже странно.
не будет хорошо, пустые значения только один момент, есть еще float, которые преобразуется с потерей данных.
Поэтому, если идти по этому пути, перепроверяйте правила преобразования ключей в php.