я так application-level сервисы делаю

идеальный метод когда тебе нужен класс-операция

когда нужна функция с интерфейсом))

когда нужна функция с интерфейсом))

ну на самом деле функция с интерфейсом и/или зависимостями своими

ну эт если регать как сервис

ну я регаю как сервис)

а такого что бы мне где-то нужна была просто функция с интерфейсом - такого небыло

ну и слишком высока стоимость для "type safty"

идеальный метод когда тебе нужен класс-операция

а зачем может понадобиться класс-операция? Ну, например

а зачем может понадобиться класс-операция? Ну, например

саги, хэндлеры команд, юзкейсы

завернуть в анонимную функцию как бы более наглядно и гибко ;)

хорошо подходит для оркестрации действиями

завернуть в анонимную функцию как бы более наглядно и гибко ;)

что завернуть?)

имхо этот __invoke вообще ввели как костыль для замыканий

саги, хэндлеры команд, юзкейсы

А что есть сага?

А что есть сага?

не важно

что завернуть?)

вызов у нужного объекта нужного метода... и передать это туда, что ждет callable

Не, я просто из интереса спрашиваю

вызов у нужного объекта нужного метода... и передать это туда, что ждет callable

у тебя есть штука которая на вход принимает нечто. Это нечто тебе надо вызвать. И есть штуки которые предоставляют аргументы для этого нечта.

общий интерфейс замутить низя, ну и в целом ведут себя штуки как просто функции

ну пусть передают замыкания

и тут __invoke приходит на помощь

завернуть в анонимную функцию как бы более наглядно и гибко ;)

ты можешь сделать интерфейс, где будет только invoke с нужными параметрами и принимать только такое в аргументах. с анонимной функцией ты шопопало можно передать, не очень безопасно

ну пусть передают замыкания

$operation = function (...$args) use ($handler) { return $handler->handle(...$args); };

тип так?

большей бойлерплейта богу бойлерплейта

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

interface MyCoolPolymorphicFunction { public function __invoke(int $myCoolArgument): string; }

и? где ты его использовать будешь?

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

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

не нравится - не юзай. Если у тебя нет кейсов для __invoke то у меня они есть

ну да... так как для этого мне не нужны "специальные классы", я могу использовать любые ;)

ну да... так как для этого мне не нужны "специальные классы", я могу использовать любые ;)

давай разберемся с твоими юзкейсами

и с моими

у меня есть сервисы представляющие собой одну единственную операцию

я их использую в контроллерах так: public function registerUserAction(RegisterUserHandler $handler, RegisterUserRequest $request) { $userId = $handler($request); return new UserDetailsResource($userId); }

ты же предлагаешь мне делать так: $userId = $handler->handle($request);

причем.... просто так

потому что тебе не нравится invoke

ну... вообще это выгляди наоборот, "я присрал сюда invoke, так как мне визуально вдруг понравилось и выглядит "по взрослому" ;))) извини

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

У тебя есть интерфейс, в нем ты можешь определить метод и вызывать его.

И без проблем сможешь навестить на один класс два таких интерфейса ;) просто имена методов помнять

У тебя есть интерфейс, в нем ты можешь определить метод и вызывать его.

1. не могу, потому что это приведет к нарушению LSP 2. конкретно в данном случае интерфейс не нужен и ничем не поможет

И без проблем сможешь навестить на один класс два таких интерфейса ;) просто имена методов помнять

зачем мне это?)

return new UserDetailsResource($userId); а вот тут кста вызовется конструктор или invoke? Или оба?

return new UserDetailsResource($userId); а вот тут кста вызовется конструктор или invoke? Или оба?

это создание объекта, как ты думаешь?)

не знаю, если честно

конструктор то наверняка

ну почитай доки

что значит new в php

Шо? типа я запихнул в интерфейс __invoke вместо имени метода и это сразу перестало нарушать LSP? какой-то бред ;)

Шо? типа я запихнул в интерфейс __invoke вместо имени метода и это сразу перестало нарушать LSP? какой-то бред ;)

у меня нет интерфейсов для __invoke

это у @Enleur кейсы такие видать есть

на пхп редко)

interface MyCoolPolymorphicFunction ;)

это просто пример что ты так сможешь замутить полиморфную функцию, late binding и при этом проверка на соответствие типов

я все еще не вижу аргументов

чем тебе не нравится __invoke

по пунктам

объективно

у invoke по сути одна задача - возможность передать объект туда, где нужно callable... все остальное - это как бы раскраски, которые лишь ухудшают читабельность

у invoke по сути одна задача - возможность передать объект туда, где нужно callable... все остальное - это как бы раскраски, которые лишь ухудшают читабельность

аргументируй про читабельность

я подобного не замечал

какой аргумент использовать getFoo вместо __get() { ... if (foo) ? :)

так никто же не вызывает явно __invoke чаще всего

ну вот у меня взвывает когнитивный диссонанс - это уже аргумент ;)

так никто же не вызывает явно __invoke чаще всего

никто и не должен

ERROR: S client not available

какой аргумент использовать getFoo вместо __get() { ... if (foo) ? :)

никакого, тут действует аксиома эскобара. И то и то - симптом нарушения закона деметры и ломает information hiding

с __invoke же мы ничего не нарушаем и ничего не ломаем.

другой вопрос - как ты без __invoke реализуешь нечто что должно вести себя как функция (потому что зачем выдумывать название для метода когда у тебя название класса и так определяет поведение) которой нужны какие-то зависимости и ты хочешь их спрятать. Предлагаешь спрятать все в лямбду где-то на уровень выше? увы наши DI контейнеры так не умеют и вообще в php с этим все плохо

ну вот у меня взвывает когнитивный диссонанс - это уже аргумент ;)

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

У кого-то было такое, что в коде вызывается функция substr_count, а на деле mb_substr_count() ? у них разные аргументы, в результате получается Warning: mb_substr_count(): Unknown encoding "0" in Это в сорсах Твига, класс Compiler

Впечатление будто где-то овверрайд, но хз

мне нравится идея с репозиторием и __invoke

https://youtu.be/rzGeNYC3oz0?t=2676

метку поставил

У кого-то было такое, что в коде вызывается функция substr_count, а на деле mb_substr_count() ? у них разные аргументы, в результате получается Warning: mb_substr_count(): Unknown encoding "0" in Это в сорсах Твига, класс Compiler

если ты врубил override в настройках mbstring nо так и будет

мне нравится идея с репозиторием и __invoke

что за идея?

я знаю идею делать интерфейс репозитория таким же как у коллекций, а с __invoke в репосах не знаком

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

если ты врубил override в настройках mbstring nо так и будет

Ничего вроде не врубал, на апаче другие сайты норм, но сейчас проверю. Спасибо за наводку

метку поставил

а, не для репозиториев а для запросов?

да, активно юзаю

+

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

в чем эта разница выражается и какой вред несет?

потому что у меня горит уже от одно репозитория на 10к строк

потому что у меня горит уже от одно репозитория на 10к строк

мы ж уже поднимали этот вопрос - делигирование ответственности с репозитория в объекты-запросы это норм тема

другой пример - нотификейшены

мы ж уже поднимали этот вопрос - делигирование ответственности с репозитория в объекты-запросы это норм тема

да норм, но не все это делают :)

$notificator->send(new WelcomeNotification($user->email(), $user->id()));

к слову, на текущем проекте мы пока тоже этого не делаем

жрём кактус

вред в том, что кому-то после тебя этот код читать и долго думать, почему у аргумента описан интерфейс, а мы его как функцию

когда ответ "причин нет, просто программисту так показалось симпатичнее" тогда неверное использование

вред в том, что кому-то после тебя этот код читать и долго думать, почему у аргумента описан интерфейс, а мы его как функцию

за полтора года что я юзаю __invoke ни разу не сталкивался с такими проблемами. За это время через проект прошло где-то 10 новых разработчиков с разным уровнем и бэкграундом

мне кажется что "вред надуман"

либо приведи конкретный пример

и ты в состоянии ответить, почему так лучше, чем вызов метода?

и ты в состоянии ответить, почему так лучше, чем вызов метода?

мне не надо придумывать имя методу - это уже плюс. Минусов не вижу.