[elixir-core:7828] [Proposal] Add GenServer.query and GenServer.handle_query

2018-01-30 Thread 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

[elixir-core:7829] Re: [Proposal] Add GenServer.query and GenServer.handle_query

2018-01-30 Thread Ben Wilson
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

Re: [elixir-core:7829] Re: [Proposal] Add GenServer.query and GenServer.handle_query

2018-01-30 Thread 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

Re: [elixir-core:7831] Proposal: allow newline after `with`

2018-01-30 Thread José Valim
In the with proposal we explain that "with" was meant to mirror for-comprehensions. It has been also discussed that nowhere in Elixir we traverse the body retrieving expressions and that's not a precedent we want to introduce in the core language itself. *José Valimwww.plataformatec.com.br

Re: [elixir-core:7831] Proposal: allow newline after `with`

2018-01-30 Thread OvermindDL1
I'm still quite curious why `with` is not entirely in the body like `cond` and `case` and so forth is (ditto with `for`), so it'd be: ```elixir with do %{x: x} <- y x end ``` It follows the pattern of cond and so forth, no weird comma's needed, no weird prefix `do:` or so forth, you only

Re: [elixir-core:7826] Proposal: allow newline after `with`

2018-01-30 Thread José Valim
Good call Ben! The formatter will rewrite it though, while it does keep parens. *José Valimwww.plataformatec.com.br Founder and Director of R* On Tue, Jan 30, 2018 at 1:46 PM, Ben Wilson wrote: > This is achievable with `\` btw: > >

[elixir-core:7823] Proposal: allow newline after `with`

2018-01-30 Thread Po Chen
x = %{x: 1} with %{x: x} <- x do IO.inspect x end ^ This works. x = %{x: 1} with %{x: x} <- x do IO.inspect x end ^ This is a syntax error. Proposing that the latter should be allowed for 2 reasons: 1) it looks like it should work ¯\_(ツ)_/¯ this sounds like trolling but is really not.

Re: [elixir-core:7823] Proposal: allow newline after `with`

2018-01-30 Thread José Valim
Imagine you have this code: foo = 1 bar = 2 foo bar do :ok end Would you expect it to be equivalent to: foo = 1 bar = 2 foo bar do :ok end It isn’t because “foo” in its own line is a valid expression. Replace “foo” by “with” and you can see why your

Re: [elixir-core:7825] Proposal: allow newline after `with`

2018-01-30 Thread Po Chen
Ah I thought `with` was part of the language, then I realized how small the language core is. Now I wish the language is actually a little bigger :S mixed feelings. Thanks for the reply! On Tuesday, 30 January 2018 23:20:49 UTC+11, José Valim wrote: > > Imagine you have this code: > >foo =

Re: [elixir-core:7826] Proposal: allow newline after `with`

2018-01-30 Thread Ben Wilson
This is achievable with `\` btw: with \ %{x: x} <- y do x end On Tuesday, January 30, 2018 at 7:39:07 AM UTC-5, Po Chen wrote: > > Ah I thought `with` was part of the language, then I realized how small > the language core is. > Now I wish the language is actually a little bigger :S mixed

Re: [elixir-core:7837] Proposal: Allow IO.inspect to accept a function as argument

2018-01-30 Thread José Valim
We don't plan to include such functionality for now. I am not convinced the generic function is generally useful and I am not sure an option to IO.inspect will be used that frequently other than a handful of developers that read the fine print. I understand the latter is not a strong argument

[elixir-core:7823] big data training in chennai

2018-01-30 Thread rose bk
Besant Technologies Chennai & Bangalore you will be able to get vast experience by transforming your ideas into actual new application and software controls for the websites and the entire computing enterprise. To make it easier for you Besant Technologies at Chennai & Bangalore is

Re: [elixir-core:7835] Proposal: allow newline after `with`

2018-01-30 Thread José Valim
Please open up a bug report! *José Valimwww.plataformatec.com.br Founder and Director of R* On Wed, Jan 31, 2018 at 12:27 AM, Po Chen wrote: > Hi Jose, > > I just tried going with parens, the formatter does not seem to keep parens >

Re: [elixir-core:7835] Proposal: allow newline after `with`

2018-01-30 Thread Po Chen
Hi Jose, I just tried going with parens, the formatter does not seem to keep parens either in this case.. On Wednesday, 31 January 2018 03:13:41 UTC+11, José Valim wrote: > > In the with proposal we explain that "with" was meant to mirror > for-comprehensions. It has been also discussed that

Re: [elixir-core:7833] Proposal: Allow IO.inspect to accept a function as argument

2018-01-30 Thread marcus
Any other thoughts on this? I'd like to continue the discussion or move forward with a decision to include or not include something like IO.inspect with an :apply option. I'm very open to changes in the name of the option, but the general functionality of a function that can transform the item

Re: [elixir-core:7833] Re: [Proposal] Add GenServer.query and GenServer.handle_query

2018-01-30 Thread 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} On 31 January 2018 01:48:54 GMT+11:00, "José Valim"

Re: [elixir-core:7836] Re: [Proposal] Add GenServer.query and GenServer.handle_query

2018-01-30 Thread 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