Не думаю, что % любящих подрочиться с каким-нибудь говном выше нормальных адекватных людей, которые ценят свои нервы и время.

Ну, т.е. потратить неделю чтобы допилить срань это не дрочево? )

нет, я бы окунулся с головой в бочку с дерьмомсолидом и начал хуячить никому не нужные абстракции *fix

нет, я бы окунулся с головой в бочку с дерьмомсолидом и начал хуячить никому не нужные абстракции *fix

Даже тут максимум 2 - входной файл , да и все наверное, т.е. даже 1. Можно его разделить на два вход/ выход. конец

да тут точно на неделю

Нет, если я всегда юзаю газл, то абстранции над ним мне не нужны

Твой предметный код не должен работать с газлами, другими клиентами. Он должен работать с каким нить FileDownloader или с HttpClient В целом можно юзать и их интерфейсы основные, потом в случае чего в composer прописать на свою реализацию через psr4

ты же понимаешь что у каждой такой либы есть свои эксепшоны, свои настройки и прочее второстепенно хелперское говно?

по сути ты предлагаешь обернуть каждый сторонний пакет в свою обертку

и как часто вы меняете пакеты на альтернативные или заменяете своей реализацией? есть метрики?

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

Ты должен смотреть, какой функционал нужен твоему коду, какие нужны ответы, с чем ты будешь работать

потому что у хттп клиента могут быть разные опции\параметры, и мы должны учитывать это в возможных реализациях, чтобы не трогать нашу обертку

т.е. под каждое действие у меня будет свой клиент?

Зависит что тебе надо , если у тебя обычный запрос просто обычный request(.. . .. .) как у газла, этого хватит

т.е. ты мапишь респонс от адаптера на свой? )

попутно пилишь свои респонс\реквесты, которые тоже адаптеры

затем добавляешь свои исключения, какие-то сервисные штуки по типу промисов газла(или как ты там делаешь это?)

т.е. по сути пишешь полный прокси клиент

допустим тебе надо поменять с газзла на симфу, где вообще всё по другому устроено, чо делать будешь? )

ну вот синк этот сраный, придется же реализовывать, а если не влезет?

Есть AsyncDownloadManagerInterface. У него есть входной параметр File($url, $pathToLocal). У него допустим есть методы isSuccess():bool , getError():?string - ну это прям вообще на пофиг пример. Эти методы будут вызываться после выполнения startDownload Есть метод AsyncDownloadManager->startDownload(File ...$files) Например нашему коду который юзает AsyncDownloadManagerInterface важны какие то два экзепшена, мы их тоже пишем SuperErrorException, ClientConnectionException Есть SymfonyDownloadManager Есть GuzzleDownloadManager У нас что есть проблемы как вытащить из File данные и применить в любом из них? Есть проблемы как их экзепшен преобразовать в SuperErrorException?

это понятно, вопрос в том, что ты заинжектишь в каччестве клиента в AsyncDownloadManager

AsyncDownloadManager это интерфейс. В нем уже конкретная работа с либой без адаптера

я думал ты предлагаешь сделать адаптер под сраный газл и юзать его во всех подобных сервисах

Ну смотри) этот кейс просто узкий. Я выше скидывал пример httpClient для обычных запросов. Т.е. над газлом обертка есть