[Proposal] Add GenServer.query and GenServer.handle_query

[Federico Bergero]

Hi all, 

         I'm proposing a new GenServer callback `query` similar to the call but which does not change the process state.

I find myself writing a lot of `handle_call` callbacks like

def handle_call(request, _from, state) do
  ...
  ...
  {:reply, result, state}
end

with the `handle_query` this could be written as 

def handle_query(request, _from, state) do
  ...
  ...
  {:reply, result}
end

This is easier to read and write. 

A common use case is when you need some computation that depends on the GenServer state. Another is when the GenServer has a side effect and the calls to the server does not changes the actual process state but an external component.

Together with the callback a new GenServer.query function should be implemented which calls the callback on the server context. 

I'm not familiar with the internals of the compiler/GenServer but this could also bring optimization opportunities.

[Ben Wilson]

Have you evaluated an Agent for your purposes? It has basically exactly this function.

[José Valim]

The goal of the GenServer is to be generic and the functionality you ask for is already possible, so I prefer to stick with the generic APIs we have so far. 

Furthermore, introducing a new word also has downsides. Newcomers already wonder about call vs cast vs info, adding a new word will make things more confusing, and we won't get anything new out of it. I personally can't think of any optimization that would be possible with such callback.

José Valim

www.plataformatec.com.br

Founder and 

Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/249e8c65-c2a2-4cbc-9956-1868d68b022f%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Dmitry Belyaev]

I am not in favour of the proposal but can see some merit in handlers not modifying the state. For that case we might still use handle_call but allow the handlers to return the result without the state part like {:reply, reply}

[José Valim]

I am not in favour of the proposal but can see some merit in handlers not modifying the state. For that case we might still use handle_call but allow the handlers to return the result without the state part like {:reply, reply}

But that is a new return type to learn. :) Plus we would also need similar for :noreply and :stop.

[Adam Lindberg]

There’s also :sys.get_state(pid|name) which returns the state for debugging purposes.

Cheers,
Adam

> On 31. Jan 2018, at 00:39, José Valim <jose....@gmail.com> wrote:
>
>
> I am not in favour of the proposal but can see some merit in handlers not modifying the state. For that case we might still use handle_call but allow the handlers to return the result without the state part like {:reply, reply}
>
> But that is a new return type to learn. :) Plus we would also need similar for :noreply and :stop.
>
>

> --
> You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4K9OtFimymiCyMOOLxmZPXqMhM2s_Y%2Ba9WkhLvmg%2BC_Aw%40mail.gmail.com.