имя методу? у тебя нет метода

имя методу? у тебя нет метода

с __invoke нету, без него - придется выдумывать что я считаю минусом))

а еще это очень простой способ заставить разработчиков делать классы только с одним публичным методом)

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

ctrl + click в phpstorm, и вот, ты уже шаришь, как это работает. Ровно 10 сек на действие и осознание

с __invoke нету, без него - придется выдумывать что я считаю минусом))

ну, в большинстве своём класс у тебя называется так же как имя метода

ну, в большинстве своём класс у тебя называется так же как имя метода

и это называется дублированием

которое ухудшает читаемость

но не handle, а что-то типа BlaBlaHandler :)

с invoke у тебя действие это имя переменной

с invoke у тебя действие это имя переменной

и что?

приведи пример того что ты считаешь "плохо"

и я тебе переименую это что бы было хорошо)

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

ну так... глагол определяет не объект, а использующий его код

с invoke у тебя действие это имя переменной

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

ну так... глагол определяет не объект, а использующий его код

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

мда? ты в русском говоришь только "регистратор"? или только "регистрирует"?

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

мда? ты в русском говоришь только "регистратор"? или только "регистрирует"?

я все еще жду конкретный пример.

инфинитивы же называются вроде

пример чего? твой пример достаточен

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

не, точно нет

пример чего? твой пример достаточен

$handler($request)?

почему нет? Пользователь -> создать, удалить, зарегистрировать, заблокировать Запрос -> принять, перенаправить

Когда ты передаешь интерфейс и потом аргумент вызываешь как функцию

почему нет? Пользователь -> создать, удалить, зарегистрировать, заблокировать Запрос -> принять, перенаправить

создать - явно не метод пользователя

как и "удалить"

Удалить пользователя, создать пользователя

я про это говорю и примеры абстрактны

Когда ты передаешь интерфейс и потом аргумент вызываешь как функцию

у тебя в интерфейсе явно написано - __invoke. Если ты хоть немного php знаешь вопросов не должно возникать.

а еще - если у тебя есть опыт с другими языками

https://www.typescriptlang.org/docs/handbook/interfaces.html

т.е. давай все классы с одним методом публичным переделаем на invoke?

в python чуть интереснее конечно - Callable(...args, returnType)

т.е. давай все классы с одним методом публичным переделаем на invoke?

ну головой то думать тоже нужно. Скорее все классы которые на самом деле не классы а операции

профит: - удобно - расширение интерфейсов уже будет вызывать массу вопросов так как будет выглядеть мягко скажем странно

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

можешь дать чёткое определение?

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

Я, кстати, как и @fes0r использую __invoke для хэндлеров команд и прочих функции, просто из-за ущербности автозагрузки php использовать просто функцию без класса нецелесообразно. Но команда должны быть готова к магии $handler($args)

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

в тестах вообще ништяк

вместо класса-мока пишешь анонимку и все счастливы

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

вместо класса-мока пишешь анонимку и все счастливы

а тайпхинт как обходишь?

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

а тайпхинт как обходишь?

так есть же тайпхинт callable

а тайпхинт как обходишь?

я юзаю callable. Я не делаю интерфейсы для __invoke

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

нуууу.... это такой себе кейс

Т.е. сервисы инжектишь по callable? и настраиваешь все в контейнере?

Т.е. сервисы инжектишь по callable? и настраиваешь все в контейнере?

callable в конструктор? э не, у меня callable как аргументы идут в методы просто

Ну вот я и удивился

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

А вот тут ты пишешь тайпхинт :)

Вот я и спрашиваю

public function changePassword(string $oldPassword, string $newPassword, callable $hashOf) { if ($hashOf($oldPassword) !== $this->password) throw new InvalidPassword(); $this->password = $hashOf($newPassword); }

нуууу.... это такой себе кейс

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

А вот тут ты пишешь тайпхинт :)

тут - да, но это контроллеры, я их не покрываю юнитами. Для этого приемочные есть

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

ну может быть, в целом валидно

а где ты их определяешь?

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

или ты на всяких там люменах/сайлексах?

Ну для маленьких приложений ок

я чаще просто беру набор пакетов из композера и всё

Для больших — мешанина, нет ясности где искать хэндер

либо в index.php он заинлайнен или еще где

Для больших — мешанина, нет ясности где искать хэндер

достаточно зайти туда, где роутинг описан, а там уже видно будет: инлайн или метод класса. если метод класса, то ctrl+click

А классы ты инициализируешь заранее?

контейнер это делает за меня

ERROR: S client not available

для этого PHP-DI юзаю

ну а так да, про размер приложений замечание верное: для маленьких такое подходит

а большие приложения я стараюсь из маленьких собирать)

поддерживаю мнение, что __invoke костыль для совместимости с callable, и его юзать только если других вариантов нету (например его юзают в php-react/promises и получаются нормальные такие js like промисы). То что @fes0r ты сегодня вызываешь свой хендлер с реквестом, завтра другой вызовет с хуй пойми чем..... имхо интерфейсы лучше и нагляднее, потому что ты соблюдаешь контракт функции. Плюс тупо поиском по проекту сможешь найти в коде кто еще использует(именно вызывает) такой же интерфейс. (полезно при рефакторинге).

Опять же, хорошо что у тебя ловко получается писать сервисы. А если завтра тебе нужно будет добавить аргумент к функции (true\false флаг посылки емейла) например. Есть хорошее правила рефакторинга - открытый для добавления но закрытый для изменения. Чтобы поддержать обратную совместимость. Что ты будешь делать? Вынесешь в парент и сделаешь два класса вместо одного? ... ну хз, "принцип наименьшего удивления" очень хреново работает в таких __invoke командах

Почему "принцип наименьшего удивления" не работает с __invoke, если это поведение четко определено?

__invoke($arg, bool $arg = false) не подойдет? Тут трэйдофф просто чтобы не создавать интерфейс ради одной имплементации.

Хотя насчет отсутствия способа зафиксировать сигнатуру при callable — разумно.

поддерживаю мнение, что __invoke костыль для совместимости с callable, и его юзать только если других вариантов нету (например его юзают в php-react/promises и получаются нормальные такие js like промисы). То что @fes0r ты сегодня вызываешь свой хендлер с реквестом, завтра другой вызовет с хуй пойми чем..... имхо интерфейсы лучше и нагляднее, потому что ты соблюдаешь контракт функции. Плюс тупо поиском по проекту сможешь найти в коде кто еще использует(именно вызывает) такой же интерфейс. (полезно при рефакторинге).

интерфейсы лучше и наглягдее когда ты можешь выделить интерфейс. В ситуациях когда у тебя это РАЗНЫЕ вещи и ты не можешь выделить общую абстракцию - ИМХО это не лучше

и это не кастыль - это способ вызывать объекты как callable

ну то есть я не вижу тут ничего кастыльного.

юзать не юзать - по ситуации и в зависимости от контекста

__invoke($arg, bool $arg = false) не подойдет? Тут трэйдофф просто чтобы не создавать интерфейс ради одной имплементации.

Для меня это главный аргумент. Вариантов стрелять себе в ногу в PHP хватает без __invoke >>Почему "принцип наименьшего удивления" не работает с __invoke, если это поведение четко определено? Четко это как? На словах? Интерфейса то нету - нету "четкости"

Для меня это главный аргумент. Вариантов стрелять себе в ногу в PHP хватает без __invoke >>Почему "принцип наименьшего удивления" не работает с __invoke, если это поведение четко определено? Четко это как? На словах? Интерфейса то нету - нету "четкости"

как именно __invoke позволяет стрелять в ногу?

Для меня это главный аргумент. Вариантов стрелять себе в ногу в PHP хватает без __invoke >>Почему "принцип наименьшего удивления" не работает с __invoke, если это поведение четко определено? Четко это как? На словах? Интерфейса то нету - нету "четкости"

интерейсы не позволяют тебе "четко" определить поведение.

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

интерфейсы лучше и наглягдее когда ты можешь выделить интерфейс. В ситуациях когда у тебя это РАЗНЫЕ вещи и ты не можешь выделить общую абстракцию - ИМХО это не лучше

Усмысле выделить абстракцию не можешь? Ты же сам говоришь - у тебя это команды. CommandInterface ебать ))))

интерейсы не позволяют тебе "четко" определить поведение.

Да, я попутал - я не про поведение, я про сигнатуру

Усмысле выделить абстракцию не можешь? Ты же сам говоришь - у тебя это команды. CommandInterface ебать ))))

нет, у меня команды - не CommandInterface. у них нет общего интерфейса

вы сегодня выходные?

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

поведение важнее сигнатур

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

уже 3-ю минуту пишет

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

Так ты сам себе злой буратино. Ты юзаешь __invoke только потому что он есть у каждого класса (считай ObjectInterface говорящий тебе, что метод __invoke существует, но с неопределенной сигнатурой). А завтра если у тебя есть ComandOneService в который ты передаешь __invoke(AType a) и ComandTwoService в который ты передаешь __invoke(BType b) то привет полные штаны удивления, потому что теперь каждому разрабу нужно знать реализацию, чтобы точно разобраться что куда можно передать. Лисков тебе говорит, что если ты реализуешь интерфейс, то не будь идиотом, и пиши реализацию так, чтобы она не ломала то, куда ты запихнешь эту реализацию. В принципе я все, согласен что каждый решит для себя сам.

Мне вот например не понятно, почему __invoke вызывает затруднения class SearchAccountAction extends Controller { public function __invoke(Request $request, AccountRepository $repository) { return $this->json(['result' => $repository->search($request->get('search'))]); } }

Так ты сам себе злой буратино. Ты юзаешь __invoke только потому что он есть у каждого класса (считай ObjectInterface говорящий тебе, что метод __invoke существует, но с неопределенной сигнатурой). А завтра если у тебя есть ComandOneService в который ты передаешь __invoke(AType a) и ComandTwoService в который ты передаешь __invoke(BType b) то привет полные штаны удивления, потому что теперь каждому разрабу нужно знать реализацию, чтобы точно разобраться что куда можно передать. Лисков тебе говорит, что если ты реализуешь интерфейс, то не будь идиотом, и пиши реализацию так, чтобы она не ломала то, куда ты запихнешь эту реализацию. В принципе я все, согласен что каждый решит для себя сам.

почему им надо что-то там знать? что куда передается - происходит вполне явно. В моем случае информация о типах не скрывается и все вполне трекается штуками вроде phpstan. > Лисков тебе говорит, что если ты реализуешь интерфейс, то не будь идиотом, и пиши реализацию так, чтобы она не ломала то, куда ты запихнешь эту реализацию. именно так. И если у меня реализации подразумевают то что они не разные реализации одного поведения а разные поведения - то между ними нельзя выделить общий интерфейс.

короч да, закрываем тему

На тему __invoke все таки один минус есть, например в тестах, если допустим в setUp каждый раз создается экземпляр такого класса и помещается в проперти тестового класса, то в тестовых методах его уже не вызвать как $this->invocableClass(), будет фатал, приходится делать не совсем красиво $this->invocableClass->__invoke()

($this->invocavleClass)()

не поможет, синтакс еррор

php 5?