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}
On 31 January 2018 01:48:54 GMT+11:00, "José Valim" <jose.va...@gmail.com>
wrote:
>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é Valimwww.plataformatec.com.br
><http://www.plataformatec.com.br/>Founder and Director of R&D*
>
>On Tue, Jan 30, 2018 at 3:25 PM, Ben Wilson <benwilson...@gmail.com>
>wrote:
>
>> Have you evaluated an Agent for your purposes? It has basically
>exactly
>> this function.
>>
>> On Tuesday, January 30, 2018 at 9:17:08 AM UTC-5, Federico Bergero
>wrote:
>>>
>>> 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.
>>>
>> --
>> 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+unsubscr...@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
>>
><https://groups.google.com/d/msgid/elixir-lang-core/249e8c65-c2a2-4cbc-9956-1868d68b022f%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>--
>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+unsubscr...@googlegroups.com.
>To view this discussion on the web visit
>https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4Koo0LRU9J8Eiwy0T1-NZZx96mJved%2BAQ-LPQ1KwPH9YQ%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/elixir-lang-core/B4359D03-F949-4EE9-9740-C832E560C6B9%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
