да как обычно, программист пишет для себя, а не для людей. Я уже привык к подобным глупостям.

ты плоховато себе вещи представляешь, итераторы в симфони не для красоты нужны, а чтобы что-то вычислить на момент обращения, иногда просто отдать подготовленный массив нельзя, тк данные могут как-то поменяться. либо их инициализация слишком тяжела, чтобы ее делать впустую. то есть тебе подготовили массив errors на условных 20 мегабайт в памяти и 100мс их подготовки, а ты ими не воспользовался, тк в этом случае оно тебе было не нужно. а платят за это все пользователи фреймворка, ведь у всех и каждого происходит эта инициализация. поэтому симфони выбрали как раз разумный подход - ты платишь только за то, что используешь. а что ты решил поиграться в красивый код, который не умеет в итераторы, это, в общем-то, сугубо твои личные половые трудности. пхп вообще слабо для фп-like годится: он и неконсистентный, и неудобный, и не выразительный

ты плоховато себе вещи представляешь, итераторы в симфони не для красоты нужны, а чтобы что-то вычислить на момент обращения, иногда просто отдать подготовленный массив нельзя, тк данные могут как-то поменяться. либо их инициализация слишком тяжела, чтобы ее делать впустую. то есть тебе подготовили массив errors на условных 20 мегабайт в памяти и 100мс их подготовки, а ты ими не воспользовался, тк в этом случае оно тебе было не нужно. а платят за это все пользователи фреймворка, ведь у всех и каждого происходит эта инициализация. поэтому симфони выбрали как раз разумный подход - ты платишь только за то, что используешь. а что ты решил поиграться в красивый код, который не умеет в итераторы, это, в общем-то, сугубо твои личные половые трудности. пхп вообще слабо для фп-like годится: он и неконсистентный, и неудобный, и не выразительный

плюс с редьюсами вместо циклов вторая проблема есть: нет консистентности кода. тебе всё равно в половине мест надо писать foreach-и, ну никуда от них не деться. и получится, что половина проекта на циклах, половина на фп-like обработках. и хер знает, почему бы везде не использовать единый стиль, чтобы код от функции к функции не отличался

И почему пхпщники не любят редьюсеры...

не, это как раз нормальное решение. фп-лайк в пхп неудобен, им никто не пользуется (я тебя уверяю, это так) дальше простых map/filter. поэтому основная линия партии - это как раз императивные циклы и в целом императивная обработка. на это намекает даже то, что все эти map/filter/reduce не принимают iterable/Traversable, а требуют массивы. это прям охуенно огромные светящиеся красные буквы "чуваки, пхп для этого не предназначен, оно вам не нужно". плохо это или хорошо - отдельный вопрос, но прямо сейчас положение вещей такое, и, на мой взгляд, глупо против него переть

оно легче, читаемее, управляемее, более php-way

Блин я написал статический метод в ErrorHelper классе и забыл про эту проблему давно. У тебя же простыня нытья на три разворота экрана

А сервисы которые не зависят ни от чего это антипаттерн

А сервисы которые не зависят ни от чего это антипаттерн

Приветствую! У меня здесь закрытый бакет в AWS, поэтому я решил, что на фронт файлы с него буду возвращать через Api. Так с echo все работает, файл отображается. Но я не понимаю, как мне его вернуть со стандартным Symfony Response объектом? Или есть еще какие-то способы?

но если прям хочется пропустить этот трафик через пхп, то надо сделать что-то вроде https://symfony.com/doc/current/components/http_foundation.html#streaming-a-response

мне кажется, что тут не надо насиловать пхп (особенно, если файлы будут большими), а взять presigned urls - это такая штука, чтобы из приватных бакетов можно было отдавать файлы клиентам по секретной короткоживущей ссылке

это не надо никак настраивать в с3, это прям точно

отдавать секретные файлы через него не имеет большого смысла, они ведь всё равно не кешируются. трафик с CF стоит столько же, сколько из s3