Как вы можете параметризовать модуль gen_server?

Question

EDIT:

Я не хочу использовать параметры в качестве общего назначения для создания программ Erlang - я все еще изучаю традиционные принципы проектирования. Я также не хочу подражать ООП. Мое единственное дело здесь - сделать мои вызовы gen_server согласованными между экземплярами сервера. Это больше похоже на исправление сломанной абстракции для меня. Я могу представить мир, в котором язык или OTP сделали его удобным для использования api любого gen_server экземпляра, и это мир, в котором я хочу жить.

Спасибо Zed за то, что я показал, что моя основная цель возможна.

Может ли кто-нибудь выяснить способ использования параметризованных модулей в gen_servers? В следующем примере предположим, что test_child является gen_server с одним параметром. Когда я пытаюсь запустить его, все это я получаю:

42> {test_child, "hello"}:start_link(). 
** exception exit: undef 
    in function test_child:init/1 
     called as test_child:init([]) 
    in call from gen_server:init_it/6 
    in call from proc_lib:init_p_do_apply/3 

В конечном счете, я пытаюсь выяснить способ использовать несколько именованных экземпляров gen_server. Насколько я могу судить, как только вы начнете это делать, вы больше не сможете использовать свой симпатичный API и бросать сообщения в своих экземплярах с помощью gen_server: call и gen_server: cast. Если бы я мог указать экземплярам свои имена, эту проблему можно было бы смягчить.

Answer 1

-module(zed, [Name]). 
-behavior(gen_server). 

-export([start_link/0, init/1, handle_cast/2]). 
-export([increment/0]). 

increment() -> 
    gen_server:cast(Name, increment). 

start_link() -> 
    gen_server:start_link({local, Name}, {?MODULE, Name}, [], []). 

init([]) -> 
    {ok, 0}. 

handle_cast(increment, Counter) -> 
    NewCounter = Counter + 1, 
    io:format("~p~n", [NewCounter]), 
    {noreply, NewCounter}. 

Этот модуль работает отлично для меня:

Eshell V5.7.2 (abort with ^G) 
1> S1 = zed:new(s1). 
{zed,s1} 
2> S1:start_link(). 
{ok,<0.36.0>} 
3> S1:increment(). 
1 
ok 
4> S1:increment(). 
2 
ok 

Answer 2

Я думаю, что вы не должны использовать эту функцию, таким образом. Похоже, вы идете после OO-подобного интерфейса к вашим gen_servers. Вы используете локально зарегистрированные имена для этой цели - добавьте много общего состояния в вашу программу, которая равна The Bad Thing. Только важные и центральные серверы должны быть зарегистрированы с register BIF - пусть все остальные будут неназванными и управляться каким-то менеджером поверх них (который, вероятно, должен быть зарегистрирован под каким-то именем).

Answer 3

На этот ответ две части. Во-первых, вы, вероятно, не хотите использовать параматизированные модули, пока не освоитесь с Erlang. Все, что они дают вам, это другой способ передать аргументы.

-module(test_module, [Param1]). 

some_method() -> Param1. 

эквивалентно

-module(test_non_paramatized_module). 

some_method(Param1) -> Param1. 

Бывший не покупает вам много на всех, и очень мало существующий Erlang код использует этот стиль.

Обычно принято передавать аргумент имени (при условии, что вы создаете несколько подобных gen_servers, зарегистрированных под разными именами) для функции start_link.

start_link(Name) -> gen_server:start_link({local, Name}, ?MODULE, [Name], []). 

---

Вторая часть для ответа заключается в том, что gen_server совместим с paramatized модулями:

-module(some_module, [Param1, Param2]). 

start_link() -> 
    PModule = ?MODULE:new(Param1, Param2), 
    gen_server:start_link(PModule, [], []). 

Param1 и Param2 будут доступны во всех функциях gen_server обратного вызова.

Как отмечает Zed, поскольку start_link принадлежит к paramatized модуля, вам нужно будет сделать следующее для того, чтобы назвать его:

Instance = some_module:new(Param1, Param2), 
Instance:start_link(). 

Я считаю, что это особенно некрасиво стиль - код, вызывающий some_module:new/n должен знать количество и порядок параметров модуля. Код, который вызывает some_module:new/n, также не может находиться в some_module. Это, в свою очередь, затрудняет горячее обновление, если число или порядок параметров модуля изменяются. Вам нужно будет координировать загрузку двух модулей вместо одного (some_module и его интерфейса/конструктора), даже если бы вы могли найти способ обновления кода some_module. В незначительной заметке этот стиль несколько усложняет grep-код для использования some_module:start_link.

---

Рекомендуемый способ передать параметры gen_servers явно с помощью gen_server:start_link/3,4 аргументов функции и сохранять их в состоянии значения вы вернетесь из ?MODULE:init/1 callack.

-module(good_style). 

-record(state, {param1, param2}). 

start_link(Param1, Param2) -> 
    gen_server:start_link(?MODULE, [Param1, Param2], []). 

init([Param1, Param2]) -> 
    {ok, #state{param1=Param1,param2=Param2}}. 

Используя этот стиль означает, что вы не будете пойманы различными частями OTP, которые еще не в полной мере поддерживают paramatized модули (новая и еще экспериментальная функция). Кроме того, значение состояния может быть изменено во время работы экземпляра gen_server, но параметры модуля не могут.

Этот стиль также поддерживает горячее обновление с помощью механизма изменения кода. Когда вызывается функция code_change/3, вы можете вернуть новое значение состояния. Не существует соответствующего способа вернуть новый экземпляр параматизированного модуля в код gen_server.

Answer 4

Я просто хочу сказать две вещи:

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

• никогда, НИКОГДА, НИКОГДА не , НИКОГДА не использовать форму, которую вы пытаетесь! Это осталось от старых дней, которые никогда не имели в виду то, что вы намеревались, и теперь сильно устарели.