а в каких случаях норм не знать свойства объекта?

В админке. Любители рассматривать внутренности персистентного лейера это очень ценят.

спасибо за объяснение, но ниче непонятно)

А выдача функции dump не всем может нравиться.

не в плане, что ты криво объяснил, а мне мозгов пока не хватает)

К админке часто добавляют если не  требование дать редактор строк конкретных таблиц (плевать, что есть бизнес-логика и всё такое), то хотя бы полное отображение того, как оно в базе: со всеми полями.

мм..таких требований пока не встречал) но в целом понятно

Я ещё встречал менеджеров, которые отчёты напрямую с помощью SQL делают. А потом поднимают вопрос на более высоком уровне, чтобы им их процессы разработчики не ломали, и всё: схему данных можно отливать в бронзе.

А ещё требования ставят, типа в каждой таблице в базе должны быть такие то поля с такими то данными

Чтобы отделу аналитики было проще запросики делать

Великолепный план. Просто охуе****, если я правильно понял. Надёжный, б**ть, как швейцарские часы.

Все решилось удалением бандла nelmio и использованием сваггера на прямую

верно, зачем лечить ногу, если можно отрезать)

нога чужая, чобынет)

То не нога а опухоль

Подскажите плиз по форме:
Тривиальная задача: есть choiceType на основе данных из БД, который много где используется. В каждой форме дергаю репозиторий, достаю данные формирую массив, вставвляю в choices[]. Решил вынести в  отдельный тип и уже его просто вкладывать в формы. Но вложенный тип не может  заинжектить репозиторий автоматом... Какой грамотный путь в этой задаче или в каждой форме инжектить репозиторий и т.д. ?

Т.е. хендлеры без единого интерфейса.

Тогда вопрос - зачем массивом передавать данные им, если можно нормально разложить по разным аргументам?

Если мало - то разные аргументы, если много - то массив. Массив в целом идея была не очень.

И последний вопрос.
Если на каждый случай делать по handler без интерфейса, то чем этот handler лучше контроллера?