It could be that, sure.
Sadly, Dializer is by no means a home run of static analysis wins. It’s slow and cryptic, which makes it a hassle to work with. The information it gives is helpful, but it definitely makes you work for it.
JEG2
Author of Designing Elixir Systems with OTP
Fl4m3Ph03n1x
True. But I still think that having some form of analysis is better than having none. Or perhaps you disagree with me?
I have the impression from the book that you use Dialyzer in your daily work - please correct me if I am wrong, I would love to know why you don’t use it (if you don’t) or what alternatives you think are better.
I have a few more questions regarding the book (please keep in mind I ask as I read, I have not yet finished the whole thing).
On page 109 we create our first GenServer and we add the following callback to it:
def init(quizzes) when is_map(quizzes), do: {:ok, quizzes}
def init(_quizzes), do: {:error, "quizzes must be a map"}
This translates to the following spec:
@spec init(any) :: {:error, String.t} | {:ok, map}
Which according to the init specification (and dialyzer) is incorrect:
The return type
{'error', binary()} in the specification of init/1 is not a subtype of
'ignore' |
{'ok', _} |
{'stop', _} |
{'ok', _,
'hibernate' | 'infinity' |
non_neg_integer() |
{'continue', _}}, which is the expected return type for the callback of the 'Elixir.GenServer' behaviour
I know I am likely missing something here. But perhaps it should be def init(_quizzes), do: {:stop, "quizzes must be a map"} instead ?
Another thing, is that I noticed you are using quiz.title as key for the quizzes map. Given that we will have many quizzes at the same time, won’t this be dangerous because it will allow key clashes?
What would the be the downsides of using reference() as an id for a quiz when creating one?
0
JEG2
Author of Designing Elixir Systems with OTP
I tend to use it when building libraries, to provide even more assurance that I’m building something robust.
I tend not to bother when I’m building applications, because of the previously mentioned hassle. This is total laziness and my part and it’s bad. Still, it’s kind of telling that the tool pushes me to this.
You are 100% correct. Great catch!
It’s a fair point. Some tradeoffs are definitely made to make the book code easier to follow.
You could use references, as you suggest, but then you need to give user code some means of finding the reference they are currently interested in.
2
Fl4m3Ph03n1x
I am glad I am somehow contributing to the great work you guys have been doing. Even though my approach may not be the best sometimes, that is always my end goal ! 
That is correct. PragDave introduced a concept in one of his courses called a Tally. A tally is a special representation of the state we give to the user. In this case, the state would be the quizzes map, and a tally could be a part of the map plus some extra information the user needs. This is a pattern used in FP I was not aware of before trying his courses, but I have had difficulty applying it in other places.
- Have you ever heard of giving tally’s to the client?
- If so, what are your thoughts on this pattern? How would it (hypothetically) fit the mastery example (if at all)?
On page 111 you present the user with this code snippet:
def quiz_fields(), do:
%{ mastery: 2, title: :simple_addition}
Here you create this function that helps us create a quiz by setting some fields. As you can see in this map, the title field is an atom, yet on page 49 you specify the quiz.title is of type String.t. In a discussion we had previously, you mentioned using Strings for scenarios where the input comes from users is better because we don’t fill up the atom’s table (and avoid a crash).
Am I missing something here? Could you please elaborate on your decision to use an atom for the title instead of a String ?
On page 118 you append errors to the list of errors instead of prepending. In the first chapters you specifically recommend prepending to lists rather than appending to them. Could you help me understand the benefits of taking a different approach here?
0
JEG2
Author of Designing Elixir Systems with OTP
Sorry, but I’m not familiar with this definition of a Tally. I tried to Google it, but I don’t think I’m finding the right concept.
I think this is just a symptom of having two authors. I intended for the title to be a string for the reasons mentioned. My co-author wrote the code using atoms, which to be fair does seem just fine for the tests he uses them in. I guess we should say either is allowed.
It felt important to me to keep the errors in the order they are encountered and I really doubt we’re going to be dealing with large enough lists of errors that performance would suffer. I made a calculated exception here.
3
Fl4m3Ph03n1x
Thank you for your detailed replies!
It is truly inspiring to have someone answer all my questions. I know I can be a bit heavy sometimes, but I want you to know I really appreciate all the time you are spending in answering them!
I will keep on reading and for sure keep on posting!
1
Fl4m3Ph03n1x
On page 122 you have this code snippet for a file called mastery.ex
def build_quiz(fields) do
with :ok <- QuizValidator.errors(fields),
:ok <- GenServer.call(QuizManager, {:build_quiz, fields}),
do: :ok, else: (error-> error)
end
What caught my attention here is the call GenServer.call(QuizManager, {:build_quiz, fields}).
Why have the authors decided to make a GenServer.call instead of using the Public API QuizManager already offers, namely the build_quiz function previously defined?
Could someone help me understand the technical reasons behind this decision? (performance issues, usage issues, etc).
In page 122 ins the function add_template, since we are not validating the title, what would keep me from setting the title as a function or some other thing? Did the authors decided to not validate the title because such a validation was not needed?
def add_template(title, fields), do:
with :ok <- TemplateValidator.errors(fields),
:ok <- GenServer.call(QuizManager, {:add_template, title, fields}),
do: :ok
0
JEG2
Author of Designing Elixir Systems with OTP
I think this is just a simple error on our part. Thanks for catching it.
Titles are really just for the creator. It’s the name you give a thing so you can refer back to it later. The system doesn’t really care what it is.
0
Fl4m3Ph03n1x
If this is the case I would like to point out that the add_template, select_question and answer_question functions of the mastery.ex file all have the same issue.
On a separate note, why doesn’t the public API of QuizManager have a function to start it?
Currently if you want to spin up a QuizManager you need the following code:
def start_quiz_manager, do:
GenServer.start_link(QuizManager, %{}, name: QuizManager)
My question is, why not have a public function in the API for that as well?
def start_quiz_manager, do:
QuizManager.start() #inside it calls GenServer.start_link(QuizManager, %{}, name: QuizManager)
If the purpose of the public API of QuizManager is to hide the gritty details and the low levels calls to GenServer, why wasn’t a start function also added for the public API?
Would love to have your opinion !
0
JEG2
Author of Designing Elixir Systems with OTP
OK, I actually took the time to look this time and I was wrong about us being wrong. 
(It’s hard for me to check exact pages, because my local book is in a different state than your beta book.)
We start off showing these bare calls and save the API wrapping for the next chapter so we can use it to address other concerns like dynamic supervision. Keep reading. We get there!
Same answer. It’s in the next chapter.
1