Jak sparametryzować moduł gen_server?

Question

EDYTOWANIE:

Nie zamierzam używać parametrów jako ogólnego celu budowania programów Erlang - wciąż uczę się tradycyjnych zasad projektowania. Nie zamierzam też naśladować OOP. Moim jedynym celem jest uczynienie moich połączeń gen_server spójnymi między instancjami serwera. Wydaje mi się, że przypomina to łamanie abstrakcji. Mogę sobie wyobrazić świat, w którym język lub OTP ułatwiał korzystanie z api dowolnego serwera instancji gen_server i jest to świat, w którym chcę żyć.

Dziękuję Zedowi za wykazanie, że mój główny cel jest możliwy.

---

Czy każdy może znaleźć sposób na sparametryzowanie modułów na serwerach gen_servers? W poniższym przykładzie załóżmy, że test_child jest serwerem gen_ z jednym parametrem. Gdy próbuję go uruchomić, wszystko pojawia się:

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 

Ostatecznie Próbuję wymyślić sposób korzystania z wielu nazwanych wystąpień gen_server. O ile mogę powiedzieć, jak tylko zaczniesz to robić, nie możesz już używać swojego pięknego interfejsu API i musisz wysyłać wiadomości do swoich instancji za pomocą komendy gen_server: call i gen_server: cast. Gdybym mógł podać instancji ich imiona, ten problem mógłby zostać złagodzony.

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}. 

Moduł ten działa dobrze dla mnie:

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

myślę, że nie należy korzystać z tej funkcji w ten sposób. Wygląda na to, że używasz interfejsu podobnego do OO do swoich serwerów gen_. Używasz w tym celu nazw zarejestrowanych lokalnie - to dodaje do wspólnego programu, czyli The Bad Thing. Tylko kluczowe i centralne serwery powinny być zarejestrowane pod register BIF - niech wszystkie inne będą bezimienne i zarządzane przez jakiegoś menedżera na nich (który prawdopodobnie powinien być zarejestrowany pod pewną nazwą).

Answer 3

Istnieją dwie części tej odpowiedzi. Po pierwsze, prawdopodobnie nie chcesz używać sparametryzowanych modułów, dopóki nie będziesz biegły w Erlangu. Wszystko, co ci dają, to inny sposób przekazywania argumentów.

-module(test_module, [Param1]). 

some_method() -> Param1. 

jest równoważna

-module(test_non_paramatized_module). 

some_method(Param1) -> Param1. 

Były nie kupuje Ci dużo w ogóle, a bardzo mało istniejący kod Erlang wykorzystuje ten styl.

Bardziej zwykłe jest przekazywanie argumentu nazwy (zakładając, że tworzysz kilka podobnych gen_servers zarejestrowanych pod różnymi nazwami) do funkcji start_link.

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

---

druga część odpowiedzi jest to, że gen_server jest kompatybilny z modułami paramatized:

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

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

Param1 i Param2 będzie wtedy dostępna we wszystkich funkcjach gen_server zwrotnych.

Jak wspomina Zed, jak start_link należący do modułu paramatized, to musiałby wykonać następujące czynności w celu nazwać:

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

Uważam, że jest to szczególnie brzydki styl - kod, który wywołuje some_module:new/n musi znać liczbę i kolejność parametrów modułu. Kod, który wywołuje some_module:new/n, również nie może żyć w samej some_module. To z kolei powoduje, że gorąca aktualizacja jest trudniejsza, jeśli zmieni się liczba lub kolejność parametrów modułu. Będziesz musiał skoordynować ładowanie dwóch modułów zamiast jednego (some_module i jego interfejs/moduł konstruktora), nawet jeśli uda ci się znaleźć sposób na uaktualnienie działającego kodu some_module. Nawiasem mówiąc, ten styl sprawia, że ​​nieco trudniej jest użyć bazy kodu dla zastosowań some_module:start_link.

---

Zalecany sposób przekazać parametry do gen_servers jest wyraźnie poprzez gen_server:start_link/3,4 argumentów funkcji i przechowywać je w wartości stanu powrocie z ?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}}. 

Korzystanie z tego stylu oznacza, że ​​nie zostanie złapany przez różnych częściach OTP, które nie są jeszcze w pełni obsługują moduły paramatized (nowa i wciąż eksperymentalny funkcję). Ponadto wartość stanu można zmienić podczas działania instancji serwera gen_server, ale parametry modułu nie mogą.

Ten styl obsługuje również aktualizację za pomocą mechanizmu zmiany kodu. Po wywołaniu funkcji code_change/3 można zwrócić nową wartość stanu. Nie istnieje odpowiednia metoda zwracania nowej parametryzowanej instancji modułu do kodu gen_server.

Answer 4

Chcę tylko powiedzieć dwie rzeczy:

• archaelus wyjaśnia poprawnie. Jak mówi, ostateczny sposób, w jaki pokazuje, jest zalecanym sposobem robienia tego i robi to, czego się spodziewasz.

• nigdy, NIGDY, NIGDY, NIGDY wykorzystać formularz starali! Pozostały po dawnych czasach, który nigdy nie oznaczał tego, co zamierzałeś, i jest teraz mocno przestarzały.