Come parametrizzare un modulo gen_server?

Question

MODIFICA:

Non sto cercando di utilizzare i parametri come un modo generale per costruire i programmi di Erlang - sto ancora imparando i principi del design tradizionale. Non sto nemmeno cercando di emulare OOP. Il mio unico punto qui è rendere le mie chiamate gen_server coerenti tra le istanze del server. Questo sembra più come sistemare un'astrazione rotta per me. Posso immaginare un mondo in cui la lingua o l'OTP rendessero conveniente l'uso di qualsiasi API di gen_server, ed è un mondo in cui voglio vivere.

Grazie a Zed per aver dimostrato che il mio obiettivo primario è possibile.

---

Qualcuno può trovare un modo per utilizzare i moduli parametrizzati su gen_servers? Nel seguente esempio, supponiamo che test_child sia un gen_server con un parametro. Quando provo ad avviarlo, tutto quello che ottiene è:

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 

In definitiva, sto cercando di capire un modo per utilizzare più istanze denominate di un gen_server. Per quanto ne so, non appena inizi a farlo, non puoi più usare la tua API carina e devi lanciare messaggi alle tue istanze con gen_server: call e gen_server: cast. Se potessi dire agli esempi i loro nomi, questo problema potrebbe essere alleviato.

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

Questo modulo sta lavorando bene per me:

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

Penso che non si dovrebbe usare questa funzione in questo modo. Sembra che tu stia cercando un'interfaccia simile a OO per i tuoi gen_server. Per questo scopo stai utilizzando nomi registrati localmente: aggiungi un sacco di stato condiviso nel tuo programma, ovvero The Bad Thing. Solo i server cruciali e centrali devono essere registrati con register BIF - lasciare che tutti gli altri siano senza nome e gestiti da qualche tipo di gestore su di essi (che probabilmente dovrebbe essere registrato con un nome).

Answer 3

Ci sono due parti per questa risposta. Il primo è che probabilmente non si desidera utilizzare i moduli parametrizzati finché non si è abbastanza esperti di Erlang. Tutto quello che ti danno è un modo diverso per passare argomenti in giro.

-module(test_module, [Param1]). 

some_method() -> Param1. 

è equivalente a

-module(test_non_paramatized_module). 

some_method(Param1) -> Param1. 

Il primo non comprarti molto a tutti, e molto poco codice Erlang esistente utilizza quello stile.

È più normale passare l'argomento del nome (presupponendo che si stia creando un numero di simili gen_server registrati con nomi diversi) alla funzione start_link.

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

---

La seconda parte della risposta è che gen_server è compatibile con i moduli paramatized:

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

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

Param1 e Param2 sarà quindi disponibile in tutte le funzioni gen_server callback.

Come cita Zed, come start_link appartiene ad un modulo paramatized, si avrebbe bisogno di fare quanto segue al fine di chiamarlo:

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

Trovo che questo sia un particolare brutto stile - il codice che chiama some_module:new/n deve conoscere il numero e l'ordine dei parametri del modulo. Anche il codice che chiama some_module:new/n non può vivere nello stesso some_module. Ciò a sua volta rende più difficile l'aggiornamento a caldo se il numero o l'ordine dei parametri del modulo cambiano. Dovresti coordinare il caricamento di due moduli invece di uno (some_module e il suo modulo interfaccia/costruttore) anche se potresti trovare un modo per eseguire l'aggiornamento del codice some_module. In una nota minore, questo stile rende un po 'più difficile l'uso della base di codice per gli usi di some_module:start_link.

---

Il metodo consigliato per passare parametri a gen_servers è esplicitamente tramite gen_server:start_link/3,4 argomenti della funzione e memorizzarli nel valore dello stato si torna dalla ?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}}. 

Utilizzando questo stile significa che non sarete catturati dalle varie parti del OTP che ancora non supporta completamente i moduli paramatized (una caratteristica nuova e ancora in fase sperimentale). Inoltre, il valore dello stato può essere modificato mentre l'istanza gen_server è in esecuzione, ma i parametri del modulo non possono.

Questo stile supporta anche l'aggiornamento a caldo tramite il meccanismo di modifica del codice. Quando viene chiamata la funzione code_change/3, è possibile restituire un nuovo valore di stato. Non esiste un modo corrispondente per restituire una nuova istanza del modulo parametrizzata al codice gen_server.

Answer 4

Voglio solo dire due cose:

• archaelus spiega in modo corretto. Come lui dice, l'ultimo modo in cui mostra è il modo consigliato di farlo e fa quello che ti aspetti.

• mai, MAI, MAI , MAI di utilizzare il modulo che stavi cercando! È un residuo dei vecchi tempi che non ha mai significato ciò che intendevi e ora è fortemente deprecato.