Логирование даёт вам лог и не даёт инструментов для его анализа. Ни тебе графиков потребления памяти, ни времени выполнения, ни всех SQL запросов удобно рассортированных по длительности. То есть либо вы собираете себе какой-то набор для анализа, либо долго и нудно читаете логи, тратя в разы больше времени, чем могли бы...
Пошаговая отладка типа XDebug или dbg важна когда нам интересен контекст на каждом шаге. То есть шагнули, подумали, посмотрели переменные текущего контекста и т.д. Когда же нам просто надо посмотреть, как у нас произошло выполнение запроса, остановка на каждом шаге только мешает. Да, есть инструменты типа strace, но пользоваться ими несколько менее удобно. Профайлеры — штука прекрасная, но их надо настроить и уметь использовать. Причём на тот же SQL профайлер один, на PHP другой (да ещё и собирать данные одной тулзой, смотреть другой).
XDebug не позволяет нормально получить картину по производительности (потому что сам её искажает очень сильно). Им совершенно не удобно собирать и анализировать SQL запросы. Да, есть инструменты под каждую СУБД вроде Neor Profiler, но это всё разные инструменты и надо их запускать десяток и читать каждый отдельно, чтобы получить общую картину. К тому же, не всё можно продублировать инструментом уже готовым. Тот же роутинг, например.
Мне очень не хотелось бы в PHP видеть ту же картину, что и в JavaScript: новый тренд каждые два месяца. Начинаем делать проект на трендовом фреймворке, к релизу он уже безбожно "устарел" и не поддерживается официально. Одно дело программировать ради фана и просто забивать на любую поддержку, и совсем другое — делать основу, на которой строятся и поддерживаются годами отличные проекты.
Формальное несоблюдение SemVer да, в этом случае будет. Согласен.
С другой стороны, какова вероятность того, что 2.1 с 5.6 проработает до начала 2019 без проблем? Как по мне, довольно высокая. Выбирать сейчас 7.1, как по мне — отбить охоту использовать фреймворк у тяжеловесов вроде IBM. Согласование мажорные версии у них проходит с большим скрипом как раз под конец официальной поддержки (знаю по Oracle и Siemens). Выбирать 7.0, если отбросить генерацию хайпа и рассматривать только проблемы с безопасностью, бессмысленно.
Ну как уже, когда Laravel только собирается, Symfony — не ранее ноября. PHPUnit поднял версию ради поднятия версии. Просто потому что все прыгают и я прыгну. Технически в этом необходимости не было. Теперь будут поддерживать несколько веток.
Профессионально развитее потому что фреймворк не работает на 5.6 и при этом не использует ничего из 7.0? Да ладно вам. Я бы ещё понял если бы аргументом была большая степень абстракции или меньшая связанность, но не это...
Если у нас в требованиях будет 5.4, руками мы не будем разводить, а решим проблему, если она решаема PHP-кодом, или поднимем минимальные требования, если нет.
Выпустил 2.0.9. Баги поправлены.
Выпустил 2.0.9. Баги поправлены.
Логирование даёт вам лог и не даёт инструментов для его анализа. Ни тебе графиков потребления памяти, ни времени выполнения, ни всех SQL запросов удобно рассортированных по длительности. То есть либо вы собираете себе какой-то набор для анализа, либо долго и нудно читаете логи, тратя в разы больше времени, чем могли бы...
Пошаговая отладка типа XDebug или dbg важна когда нам интересен контекст на каждом шаге. То есть шагнули, подумали, посмотрели переменные текущего контекста и т.д. Когда же нам просто надо посмотреть, как у нас произошло выполнение запроса, остановка на каждом шаге только мешает. Да, есть инструменты типа strace, но пользоваться ими несколько менее удобно. Профайлеры — штука прекрасная, но их надо настроить и уметь использовать. Причём на тот же SQL профайлер один, на PHP другой (да ещё и собирать данные одной тулзой, смотреть другой).
Да там изучать нечего. Один тулбар, пять панелек. Настраивать ничего не надо. В том же Symfony не сложнее. Изучается за вечер, а то и меньше.
Похоже, 2.0.9 будет быстрее, чем планировалось :)
XDebug не позволяет нормально получить картину по производительности (потому что сам её искажает очень сильно). Им совершенно не удобно собирать и анализировать SQL запросы. Да, есть инструменты под каждую СУБД вроде Neor Profiler, но это всё разные инструменты и надо их запускать десяток и читать каждый отдельно, чтобы получить общую картину. К тому же, не всё можно продублировать инструментом уже готовым. Тот же роутинг, например.
Это отвалилось не благодаря штуке, а в самой штуке.
И то и то интересно и нет, мы об этом не думали. Кидайте отдельными issue или pull request-ами в репозиторий.
Какой именно фильтр и что за переключение?
Готово.
Шутите?
Не так просто выпилить… но уже начали.
Этот вопрос уже много раз поднимался и много раз был дан ответ, что в 2.1 мы постепенно выпиливаем frontend-зависимости из ядра.
Про плюсы и минусы медленного SAT-солвера для PHP и JS сразу мы, естественно знаем.
А что нынче популярно в мире JS?
Когда соберёмся выкатывать, тогда пересмотрим этот вопрос ещё раз.
Мне очень не хотелось бы в PHP видеть ту же картину, что и в JavaScript: новый тренд каждые два месяца. Начинаем делать проект на трендовом фреймворке, к релизу он уже безбожно "устарел" и не поддерживается официально. Одно дело программировать ради фана и просто забивать на любую поддержку, и совсем другое — делать основу, на которой строятся и поддерживаются годами отличные проекты.
Формальное несоблюдение SemVer да, в этом случае будет. Согласен.
С другой стороны, какова вероятность того, что 2.1 с 5.6 проработает до начала 2019 без проблем? Как по мне, довольно высокая. Выбирать сейчас 7.1, как по мне — отбить охоту использовать фреймворк у тяжеловесов вроде IBM. Согласование мажорные версии у них проходит с большим скрипом как раз под конец официальной поддержки (знаю по Oracle и Siemens). Выбирать 7.0, если отбросить генерацию хайпа и рассматривать только проблемы с безопасностью, бессмысленно.
Ну а какие ещё варианты есть, если её нельзя не сломать?
По сути это одно и то же. Версионирование только отличается.
Ну как уже, когда Laravel только собирается, Symfony — не ранее ноября. PHPUnit поднял версию ради поднятия версии. Просто потому что все прыгают и я прыгну. Технически в этом необходимости не было. Теперь будут поддерживать несколько веток.
Профессионально развитее потому что фреймворк не работает на 5.6 и при этом не использует ничего из 7.0? Да ладно вам. Я бы ещё понял если бы аргументом была большая степень абстракции или меньшая связанность, но не это...
Если у нас в требованиях будет 5.4, руками мы не будем разводить, а решим проблему, если она решаема PHP-кодом, или поднимем минимальные требования, если нет.