3 ms·

Hi @SupremumLimit, that was a great article, thanks for sharing. Here are some tiny remarks, in case they help: * About dot when calling anonymous functions, I

Hi @SupremumLimit, that was a great article, thanks for sharing. Here are some tiny remarks, in case they help: * About dot when calling anonymous functions, I have just published an article I have been sitting on. I hope it clarifies a bit why it exists and its benefits for code readability: https://dashbit.co/blog/why-the-dot https://dashbit.co/blog/why-the-dot * Regarding keywords, I actually don't consider them to be a replacement for named arguments. However, given they are called "keyword lists", it is an easy association to make. I will make sure we focus more on them as optional arguments. * There is a distinction between `is_map` and `empty?` as it denotes which are allowed in guards and which ones are not. With a potential type system incoming, we may be able to enforce this too, making it easier for library authors to follow these guidelines. * Your approach to using contexts is absolutely fine. Phoenix typically does not care how you answer the context question, as long as you answer it. The goal is to avoid the case where you build an application for 18 months without considering how it should be organized. * You are 100% correct on functional components vs live components. I will make it clearer in the docs the former should be preferred.

nivertech 3y ago
1. Elixir Keywords are Erlang's proplists plus syntactic sugar (making them easier to write and read), which in turn I guess were inspired by proplists in Lisp, but there they're lists of cons-cells, not a list of 2-tuples. Also Erlang's proplists have a special case for Boolean flags, e.g. instead of [{key, true}] one can just write [key]. 2. I think Phoenix Contexts are inspired by the DDD Bounded Contexts - a strategic pattern, which seems not be relevant for a typical web app built with Phoenix. But maybe it serves as a forcing function for the developer to think about the domain and how it may evolve in the future. 3. I surprised the author didn't complained about overuse of sigils in the language ;)
SupremumLimit 3y ago
Thanks for the post about the dot, interesting stuff and the TL;DR is excellent.
bongobingo1 3y ago
> With the context above, I had to answer the following question when designing *Elixiur*: should anonymous functions have a dot when invoked or not?
- josevalim 3y ago
  Fixed, thanks!
marcandre 3y ago
I am not the OP, but I suspect the point about keywords vs map might be why was Keyword favoured over Map, i.e. why does `foo(a: 1)` compile as `foo([a: 1])` and not `foo(%{a: 1})`. Nice writeup on why the dot <3

nivertech 3y ago

1. Elixir Keywords are Erlang's proplists plus syntactic sugar (making them easier to write and read), which in turn I guess were inspired by proplists in Lisp, but there they're lists of cons-cells, not a list of 2-tuples. Also Erlang's proplists have a special case for Boolean flags, e.g. instead of [{key, true}] one can just write [key]. 2. I think Phoenix Contexts are inspired by the DDD Bounded Contexts - a strategic pattern, which seems not be relevant for a typical web app built with Phoenix. But maybe it serves as a forcing function for the developer to think about the domain and how it may evolve in the future. 3. I surprised the author didn't complained about overuse of sigils in the language ;)

SupremumLimit 3y ago

Thanks for the post about the dot, interesting stuff and the TL;DR is excellent.

bongobingo1 3y ago

> With the context above, I had to answer the following question when designing *Elixiur*: should anonymous functions have a dot when invoked or not?

josevalim 3y ago
Fixed, thanks!

marcandre 3y ago

I am not the OP, but I suspect the point about keywords vs map might be why was Keyword favoured over Map, i.e. why does `foo(a: 1)` compile as `foo([a: 1])` and not `foo(%{a: 1})`. Nice writeup on why the dot <3