Комментарии 20
Ну зачем выкладывать такие картинки для привлечения внимания с настолько жуткими уродствами?
PHP постоянно развивается.
В некоторых случаях затраты на модернизацию не стоят затраченных усилий и средств. ....
Почему нельзя развиваться не ломая совместимость? Зачем превращать язык программирования в одноразовый? Для безопасности? Люди смертны. И авторы фреймворков обязательно помрут и через пару лет их нельзя будет использовать.
В реальности никто не будет заниматься обновлением таких приложений, их попросту со временем заменят.
В результате останутся только те которые пилят крупные компании и вы будете вынуждены пользоваться только ими.
И это вообще тенденция относится ко всему софтостроению, введения искусственного устаревания во имя коммерческих целей, прикрываясь мифической безопасностью.
у меня до сих пор пригорает от отмены lts версии Laravel
Не ломая совместимость развитие превращается в набор костылей и подпорок. За примерами далеко ходить не надо. Особенно, если действительно есть куда развиваться.
совместимость ломают не потому, что левая пятка зачесалась, а потому что раньше были допущены ошибки ( или поменялась среда ), и без отказа от совсместимости нельзя двигаться дальше. Посмотрите на зоопарк строковых и array_* функций в PHP - сколько лет их ругают и требуют переделать для единообразия и чистоты, но необходимости в переделке нет, и поэтому эти функции не трогают.
на зоопарк строковых и array_* функций в PHP
Так что мешает убрать эти функции в отдельный модуль? При этом вы не ломаете совместимость, кому надо просто этот модуль подключают, а кому нет не используют.
совместимость ломают не потому, что левая пятка зачесалась, а потому что
Ломают очень уж целенаправленно и методично. И ошибками это не оправдать.
Так что мешает убрать эти функции в отдельный модуль?
Я неточно выразился. Имелось в виду, например, такое:
// строка служит первым аргументом
strtok(string $string, string $token);
parse_str(string $string, array &$result);
// строка - второй аргумент
explode(string $separator, string $string, int $limit = PHP_INT_MAX);
// субъект - третий аргумент
str_replace(
array|string $search,
array|string $replace,
string|array $subject,
int &$count = null
);
// а здесь - первый
strtr(string $string, string $from, string $to);
// поиск в строке
strpos(string $haystack, string $needle, int $offset = 0);
// поиск в массиве- $needle и $haystack в другом порядке
array_search(mixed $needle, array $haystack, bool $strict = false)Так и что мешает вынести "правильные" функции в отдельный правильный namespace.
А не правильные подключать в php.ini если требуется: ( extension=php5 )
что мешает вынести "правильные" функции в отдельный правильный namespace
Обратная совместимость
не правильные подключать в php.ini если требуется
Обратная совместимость. У старого кода не было зависимости от модуля, а теперь вдруг появилась.
Проблему беспорядка в аргументах решили обходным путём, за счёт именованных аргументов. Но пока этот подход приживётся...
Вы видимо не понимаете что такое обратная совместимость. Она абсолютно никак не мешает вводить новые функции. И если для получения полной совместимости достаточно это просто прописать в настройках этого достаточно. Те кто пишет с нуля будут использовать новые "правильные" методы. А если используется старый код это указывается явно. А вот уже при подключении модуля можно сообщать что этот модуль устарел и постарайтесь перейти на альтернативу. И должны быть примеры и документация, а не как обычно. Выкинули и кувыркайтесь как хотите. По старым функциям полно описания и книг. А почему это устарели и как именно заменить или хотя бы эмуляции старого функционала через новый - ну нафиг, сами как-нибудь догадывайтесь. И в результате: адовый адок. А если ось обновилась, то конечно же поддерживать только последнюю. Потому как там такие же олени.
Да, и получится что мы будем иметь "новую версию с новыми функциями", но будем ещё иметь кучу костылей в конфигах.
Всё со временем устаревает, и я вот не припомню языка, в ктотором ты поменяешь мажорную версию, и у тебя не то что проект не заведется (ну, исключая всякие hello world), но и там уж точно не будет костылей для возвращения "старого" поведения.
Обратная совместимость
Как именно обратная совместимость мешает добавить новый неймспейс с правильными функциями? Старый код этот неймспейс не использует, а значит его поведение не изменится.
А не правильные подключать в php.ini если требуется: ( extension=php5 )
А вот это действительно сломает обратную совместимость.
Апач уже давно умеет в fpm
Дело не в прокладке, дело в системе. Деньги дают на "фичи", но не дают на исправление ошибок. Поэтому в PHP появляются совершенно ненужные языковые конструкции, но всё ещё нет полной поддержки юникода.
Для меня идеальным PHP был бы движок PHP7 с языком PHP4. И всеми исправленными ошибками, конечно.
Сидел на php5.6, обновил до 8 по возможности, разницы не заметил толком, лучшей наверное считаю php7, с ней меньше всего проблем
Но я использую CGI версии, как-то быстрее работают и не кешируют все что не надо
Чего?) Разница хотя бы в скорости, просто колоссальная.
А там если ещё обновиться до 8.2, особенно если у тебя в проекте есть к примеру реализации стандартных интерфейсов из SPL (а если ещё и есть наследники, в которых есть оверрайды методов...). Вот там веселье начинается сначала с перелопачиванием своего кода для совместимости с тайпхинтами, потом с обновлением зависимостей, а потом с перелопачиванием снова своего же кода, для исправления совместимости с библиотеками.
При нормальной организации процесса разработки проблем с обновлением зависимостей нет: обновления происходят регулярно, проблемы несовместимости единичные, редкие, разрешаются дешево, каждый раз код нужно адаптировать лишь немного.
Ну а когда всем по 5 лет пофиг на разработку, а потом оса в одно место ужалила и бегом обновляться через 100500 версий - тогда конечно легко и дешево уже не будет, уровень бардак может быть такой большой, что дешевле будет написать с нуля, чем его разгрести.
Вся разница в подходе к организации процесса разработки в компании. Судя по диаграмме в статье, нормально процесс выстроен только у 15% - они обновляются более-менее регулярно и уже переехали на 8 версию, которой уже 3 года к слову, у 50% процесс выстроен плохо - они до сих пор на серьезно устаревших версиях, никаких причин так сильно задерживать обновление нет, а у 35% разработка по факту мертва, вообще ничего не обновляется.
Как продлить срок службы старых PHP-приложений