Symfony 5.0

Можем поздравить команду. Фреймворк явно слизывает тот же Spring, но на PHP. Работать с фреймворком приятно, документация нормальная. Но исходный код ужасный.

Мы на одном из проектов используем компоненты Symfony, при том проект был из 2000х и мы просто выкидывали велосипеды, заменяя на компоненты. Само собой делалось это постепенно и через адаптеры.

Да, кстати как-то сбоку в четверке был прикручен PSR-7, сам Request его не поддерживал. Как там сейчас дела?

Обёртки нинужны. Клоны спринга в пхп вдвойне нинужны. Серьёзно, весь кайф пхп в том, что там всё встроено в язык. А то нафигачат, а потом доклады на ютубе «на старте симфони грузит 309 файлов, мы отключили stat, стало быстрее».

да, я тоже хотел бы, чтобы в PHP была работа со строками как в Ruby из коробки

Нужно. Единственное сообщество, позитивно влияющее на развитие PHP. Чего стоит их умение писать независимые компоненты, которые применяются почти в каждом проекте

емнип symfony вообще вышли из PHP FIG, так что резонно ожидать, что на некоторые PSRы вообще забьют

Но исходный код ужасный.

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

Отличный там код. Особенно в сравнении с Yui2 и Laravel

И шо там в этом рубе? В пхп чуть ли не самые безгеморройные строки искаропки - они бинарные. Это офигенно же.

Да, погуглите как сделать аутентификацию пользователя средствами Symfony. Далее в контроллере есть методы getDoctrine(), далее почитайте код Request’a В симфони уже сейчас огромный слой Легаси.

Эм, но Laravel на половину состоит из Symfony, а Yii2 красиво написан, но монолит, за что получил по шапке. Да и много было архитектурных промахов, вроде jQuery в зависимостях.

Я об этом. Они почему то остались в своем мире. Это может не очень хорошо кончиться.

• у симфони есть неоправданная сложность в некоторых местах. В свое время много крови у меня попил security bundle, вот кстати комментарий разработчика Yii https://rmcreative.ru/blog/post/porog-vkhozhdenija-v-symfony-ili-zakryt-url-na-basic-auth

как минимум там нет mb*-костылей и крутой method chaining (причём не только для строк)

Состоит, но только в Ларавеле через app() можно абсолютно из любой части кода (вне зависимости от слоя абстракции приложения) получать инстанс приложения, что как бы не совсем ок. Yii2 - использование active record -«красиво написан»? Ну хз, спорно весьма.

Yii2 красиво написан, но монолит, за что получил по шапке

Он не монолит. Там проблема в другом, у них свой DI-контейнер и своя автозагрузка, поэтому нельзя их компоненты использовать отдельно и наоборот, притащить что-то из symfony. В Yii3 обещают всё перепилить под PSR, так что будет всё пучком.

там нет mb*-костылей

Там всё в кучу свалено. Это ещё хуже.

крутой method chaining (причём не только для строк)

Монада пишется на коленке за 5 минут.

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

Это спорное утверждение.

мне кажется пора бы уже на composer + artisan переходить с этого мамонта

Спорное - да. До того момента спорное, пока не начинаешь проект тестами покрывать.

пока не начинаешь проект тестами покрывать

И чем мешает app()? Это тот же DI, только императивный, а не декларативный.

app() - это не DI, а Service Locator… В лучших домах Ландона и Парижу упоминать такое - моветон.

Раз уж тут собрались специалисты, можете сказать как мне сделать ucfirst в утф?

это не DI, а Service Locator

Ещё раз для тупых анонов - локатор это императивный DI.

моветон

Пусть эти господа идут куда подальше. Для пыха локатор ничем не хуже DI на свойствах и т.п. потому что всё равно всё происходит в рантайме. Т.е. между

class Some {
 public function __construct(\ToInject $prop) {
    $this->prop = $prop;
 }
...
}

и

class Some {
 public function __construct() {
    $this->prop = app(\ToInject::class);
 }
...
}

я не вижу никакой особой разницы, кроме вкусовщины.

можете сказать как мне сделать ucfirst в утф

Чем тебя не устраивает очевидное mb_strtoupper(mb_substr($string, 0, 1)).mb_substr($string, 1)? Впрочем, в разных фреймворках есть свои благородные способы. В частности в symfony u($string)->title(). АПВС?

Да меня устраивает, просто php6 отменили вроде как раз из-за юникода, а теперь 7 и чето не видно все еще в роадмапе.

Впрочем, в разных фреймворках есть свои благородные способы. Норм, конечно, давайте тащить замену из сторонних фреймворков на замену нативной нерабочей функции. Я за php, если что.

Меня вообще бесят на хрен любители DI магии, парсящей аннотации и всё такое. Особенно в PHP. Я ещё как-то понимаю в Джаббе - им там пхп не хватает! Вот они и изобретают рантайм костыли. Но в скриптоте-то оно делается вообще без магических извращений.

Вопрос таки как раз не вкусовщины. Это неявная зависимость. Разработчики используют сервис локатор в коде бизнес логики, и используют эту самую неявную зависимость. Тестировать такой код становится сложнее, а перенести в другие системы так вообще невозможно.

Поздравляю симфонистов. Я Symfony не использую, но на текущее время, это единственный адекватный фреймворк в мире PHP. Со своими заморочками конечно.

Еще жду когда выкатят Laminas (продолжение Zend Framework).

Он не монолит. Монолит. Достаточно посмотреть структуру классов. У них все от Component наследуется и по всему коду есть Yii::$app

Мы не говорим про использование Yii2 AR, а про то, как сам AR внутри написан.

Состоит, но только в Ларавеле через app() можно абсолютно из любой части кода

За это руки отрывают во второй рабочий день.

Ну вот ты ж сам этими примерами ответил на свой вопрос по поводу того, как app в Laravel мешает покрывать тестами. Это ни разу не вкусовщина. В первом случае явно видно, что именно надо мокать при тестировании класса Some. Во втором этого не видно, пока не зайдешь в класс и не посмотришь конструктор. И хорошо, если только конструктор. Ведь вызовы app разраб может по всему классу рассовать - и даже в каких-нибудь хелперах. Шерстить весь код, чтобы найти места, где разраб рассовал app - ну такое себе.

И как он внутри написан? Что тогда такое «красота кода»? Для меня это архитектура, прежде всего, грамотное использование паттернов. Сам факт наличия эктив рекорд - это антипаттерн.

«За это руки отрывают во второй рабочий день.» - отрывают не отрывают, но если фреймворк дает возможность так делать, разрабы так будут делать.

Yii2 красиво написан

Теперь гляньте на эту «красоту» https://github.com/yiisoft/yii2/blob/master/framework/helpers/BaseConsole.php#L872

Что не так аутентификацией? Используешь сервис authentificationUtils для простой формы, для чего-то посложнее, используешь AuthentificationManager. Что с request? Вполне удобная реализация, особенно аттрибуты. GetDoctrine никто кроме новичков больше не использует, обычно инджектят репозиторий как сервис. Если Вы видите в иде зачеркнутый и неудаленный метод, это не значит что это плохо, это оставлено специально для совместимости пользователям с легаси проектами

А если в глубине дочерних сервисов нужно инициализировать другой сервис, когда уже использовано достаточно памяти инициируя родительские, локатор будет снова поднимать и ресолвить контейнер, что может спровоцировать закрытый out of memory, в отличие от DI

Там всё в кучу свалено. Это ещё хуже.

там есть единственный рассово верный utf8 для строк, а если тебе нужна пачка байтов - возьми пачку байтов

Монада пишется на коленке за 5 минут.

можно и обвёртку накатить за <минуту, речь то о ядре

а теперь 7 и чето не видно все еще в роадмапе

А как это связано с ucfirst? В питоне и руби якобы есть юникод, но тоже нет ucfirst. Или есть?

У них все от Component наследуется

И что? А в жабе всё наследуется от Object. Видимо жаба монолит.

по всему коду есть Yii::$app

Тот же app() вид сбоку. Ничего плохого не вижу.

Это неявная зависимость

Гораздо более явная, чем волшебные аннотации или параметры, которые непонятно, как и откуда пробрасываются.

Тестировать такой код становится сложнее

И в чём конкретно сложность?

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

ЛОЛ, а что в первом случае знание параметров конструктора возникает телепатически? Как интересно ты вообще собираешься тестировать код, который ты даже не смотришь, и тем более не знаешь что он делает?

вы меня не поняли, но да ладно.

в отличие от DI

В отличие от декларативного DI. Который сразу отрезвит всё что надо? А как он это сделает пока исполнение не дойдёт до «глубины»? Мне кажется что декларативный даже раньше загнётся, т.к. ему, в отличие от простого DI-контейнера, нужно парсить файлы и заниматься рефлексией.

но да ладно

Жаль. Интересно что же ты имел в виду?

Ну, во-первых, эти параметры, как минимум, подскажет тебе любая современная IDE. Наверное, она это делает телепатически или через астрал - не знаю.

Во-вторых, ты четко знаешь, какие именно сервисы тебе надо мокать, потому что они явным образом передаются в конструктор. В случае с app, вызов которого можно запихать куда угодно и как угодно, ты будешь лазать по всем методам, методам, которые они вызывают, трейтам и т.п. - и только потом писать моки в надежде, что ты какой-то вызов app где-то не пропустил.

«Как интересно ты вообще собираешься тестировать код, который ты даже не смотришь» - очевидно, по принципу черного ящика. Я знаю, что сервис должен принимать на вход и знаю, что я от него ожидаю. Как именно он внутри работает, для написания тестов этого уровня абстракции не важно. А в случае с app в коде я как раз должен туда внутрь лезть и копаться.

К тому же сервисный слой принято делать независимым, а с помощью app по всему коду, ты этого не получишь вообще никак. Компоненты проекта становится сильно связанными.

Убедил?)

В случае с app, вызов которого можно запихать куда угодно и как угодно

За это, как уже сказали, отрывают руки и этими руками бьют по роже. Всё должно быть в конструкторе. Кроме того, независимо от DI, свойства класса должны иметь доки с аннотациями типа, а сам класс доки с @uses.

Если ты хочешь возразить, что тут приходится полагаться на аккуратность программиста и что на это полагаться нельзя, то можешь сразу подумать о том, а что кроме аккуратности мешает указать 100500 ненужных параметров в конструкторе? Или что мешает указать более широкую зависимость, чем нужно? Да хотя бы указать параметром весь контейнер, и использовать его также как app()?

Компоненты проекта становится сильно связанными

Сильно — это сильно сказано, когда общая внешняя зависимость только одна. Зато она явная.

Убедил

Пока нет. Использование параметров конструктора для DI имеет свои большие минусы. Например у тебя есть класс и 100 подклассов. Если тебе нужно добавить зависимость, то вместо того, чтобы просто в базовом классе в конструкторе дописать одну строчку, придётся в каждом из 100 классов править сигнатуру конструктора. Такая себе абстракция.

Пока нет. Использование параметров конструктора для DI имеет свои большие минусы. Например у тебя есть класс и 100 подклассов. Если тебе нужно добавить зависимость, то вместо того, чтобы просто в базовом классе в конструкторе дописать одну строчку, придётся в каждом из 100 классов править сигнатуру конструктора. Такая себе абстракция.

Не очень понял. А разве нельзя в базовом классе просто добавить в конструктор эту зависимость, присвоить ее protected-свойству базового класса в этом же конструкторе - и спокойно из дочерних классов к ней обращаться? Зачем в каждом из 100 дочерних классов править сигнатуру конструктора? Или я не правильно понял, что ты имеешь в виду.

Не очень понял.

Он имеет ввиду, что если ты родительском классе, добавил, например Security, а в дочернем тебе захотелось EntityManager, но не хочется захламлять код перечислением всего, что притащил родительский класс, то всё очень плохо.

И приходится в родительский класс подтягивать Container, чтобы скрытно призвать все зависимости, что тебе нужны только в нём.

А, ну вообще да, есть такой момент)

В принципе соглашусь с security bundle, но с другой стороны это слишком критичная часть чтобы оставлять без присмотра. А то как было в одном проекте с yii, коллега создал контроллер и не обработал в нем авторизацию (либо экстендом класса, либо врчную обрабатывать). Роуты остались открытые анонимно. В другом проекте это привело бы к финансовым убыткам. Зато простота™ yii. Кароч палка о двух концах - хочешь секьюрность, изволь попариться, хочешь легкость в настройке - проверяй основательней/пиши свои велосипеды.

Конкретно случая Макарова, то нужно было гуглить «symfony http basic auth» и обернуть в запуск только в dev, что он и сделал собственно, но шума столько-то поднял. Вижу он достаточно субъективен к остальным фреймворкам кроме своего, что также было заметно в недавнем видео о конференции в Сербии

Зачем в каждом из 100 дочерних классов править сигнатуру конструктора

Допустим есть такое

class B {
        public function __construct(C1 $a) { ... }
}

class S1 extends B {
        public function __construct(C1 $a, C2 $b) { parent::__construct($a); ... }
}

class S2 extends B {
        public function __construct(C1 $a, C3 $b) { parent::__construct($a); ... }  
}
...

class S100500 extends B ...                                                    

Теперь тебе захотелось в B добавить ещё одну зависимость C4 $x. Твои действия?

гыыы))