ŹR
Например, строка 13 реализации стека из статьи
{new_list, new_list}
{new_list, new_list}
Это прям по солиду
Size: a a a
2019 March 20
к
Внутри самого генсервера типа нету динамического диспатча
хм, конкретно apply там нет
сделали send в процесс, процесс вызвал handle_call напрямую (как эрланг сам вызывает колбеки - хз)
сделали send в процесс, процесс вызвал handle_call напрямую (как эрланг сам вызывает колбеки - хз)
ŹR
Ведь очевидно же, что мы можем поменять genserver на что нибудь другое, и нам все еще надо будет возвращать тупл из двух одинаковых вещей
ŹR
Я уже не говорю про то, когда появится cast
ŹR
И пронять из apply где вызывать call а где cast не сможет никто и никогда
DS
И пронять из apply где вызывать call а где cast не сможет никто и никогда
apply уже внутри call/cast, тут не надо ничего понимать
к
apply уже внутри call/cast, тут не надо ничего понимать
нет в call/cast эплая, зачем там эплай-то
ŹR
нет в call/cast эплая, зачем там эплай-то
Он не о том
к
ага, понял
к
в колбеках call/cast
ŹR
Он про реализацю
DS
Это прям по солиду
я уже хз, можно было бы и адаптер бахнуть, но тут и так примеров больше чем текста, а пример с apply привлек больше внимания, чем предложение выносить бизнес логику из генсервера
ŹR
apply уже внутри call/cast, тут не надо ничего понимать
Да, согласен, тут ты прав - просто будут одинаковые под копирку handle_cast и handle_call, а что именно вызывается написано в api
ŹR
Адаптер был бы солидно, но тогда возможно не получится написать унифицированный apply
DS
Я уже не говорю про то, когда появится cast
def handle_cast({function_name, arguments}, state) do
{_reply, new_state} = apply(StackImp, function_name, [state] ++ arguments)
{:noreply, new_state}
endDS
было бы так, т.к. ответ не нужен
DR
Разница в том, что gen_server уже делает apply, а в реализации с форвардом делается ещё один apply. Для тестирования можно делать handle_call напрямую, а чтобы выносить логику в другой модуль и дергать через apply - для этого должна быть более везкая причина (возможность в разные имплементации GenServer-ов воткнуть имплементацию логики).
ŹR
Я бы пользовался стандартным механизмом, по крайней мере нету иллюзий что коллбэки оторваны от генсервера, либо генерировал похожий apply через макрос или даже руками.
Кроме того, я бы не советовал так тестировать генсервер, потому что один сервер это один юнит, и должны быть веские причины чтобы эти функции так отдельно тестировать…
Кроме того, я бы не советовал так тестировать генсервер, потому что один сервер это один юнит, и должны быть веские причины чтобы эти функции так отдельно тестировать…
к
(может быть опять не в тему, но я повторюсь, gen_server не делает apply)
ŹR
Dmitry Russ (Aleksandrov)
Разница в том, что gen_server уже делает apply, а в реализации с форвардом делается ещё один apply. Для тестирования можно делать handle_call напрямую, а чтобы выносить логику в другой модуль и дергать через apply - для этого должна быть более везкая причина (возможность в разные имплементации GenServer-ов воткнуть имплементацию логики).
Где вы нашли apply в gs то? Может я чего не знаю