I wrote a a function that delete the content of database.
Consider following code snipped:
defmodule Seeds do
def delete_db(values) when is_list(values) do
cond do
length(values) > 0 ->
Repo.delete_all(values)
true ->
{:ok}
end
end
end
When I call the delete_db function, it will happen a side effect, the data on db will be deleted.
My question is, do I follow functional specification?
Thanks
What exactly does that mean? It’s not technically a function, no, because it has a side-effect. The reality of Erlang & Elixir is that there can be side-effects in procedures anywhere. Pure functions in these languages are an ideal; something to strive for, not law.
It’s also not law in Haskell, for example, but is clearly marked as happening, at least. I would suggest not fretting about using side-effects in Elixir. Instead, pay attention to where you can do without them by passing data. Don’t do this to blindly follow ideals, but to get code that can be used in any context and with predictable results.
You won’t really get pure functions that do operations on databse, files, environment variables etc. etc.
the reason is that they interface with impure external environment. So I do not think there is anything wrong from that point of view in your code.
So my code is ok?
Can you show me please an example?
The essential quality of a “pure” function is that it always has the same output for the same inputs.
You could make your function pure by passing in the state of the database and returning the state of the database, However, that’s not really practical. But you should strive to have anything you operate on in the function passed in as an input, rather that magically appearing from the ether.
def delete(DB, values ) do
Kernal.apply(DB, :delete_all, values )
end
This makes the code much easier to test and also limits the side effects to as small a surface area as possible. There is obviously a trade-off between adding needless complexity and applying this principle. To misquote Terry Pratchett
That’s why there are rules, so you’ll think a bit before you break them.
Hey there. Your function is generally fine, but has a couple of style issues. First, it’d be clearer to use Enum.any? instead of lenght(values) > 0. Not only is this more readable, we don’t actually care what the length is, so long as there’s at least one item. No point in counting them all.
Secondly, you should just return :ok instead of {:ok}. There’s no point in wrapping it in a tuple.
With these changes in mind, your best bet is something like:
def delete_db(values) when is_list(values) do
if Enum.any?(values) do
Repo.delete_all(values)
else
:ok
end
end
Well, with refactoring in mind it might be better to simply do this:
def delete_db([]) do
:ok
end
def delete_db([_h | _t] = values) do
Repo.delete_all(values)
end
It’s short, splits the procedure up into cases neatly and asserts structure at the same time.
As a final tweak, you can have the second clause just be def delete_db(values) because the only way it gets there is if it isn’t an empty list. You could add when is_list(values) if you really wanted to as well
Think of it this way:
If something needs updating, let’s say a map of some keys and values, you could conceivably have a process that guards that state and the way you interact with it is to send messages to that process in order to modify the data.
When you use this model you run the risk of having the process crash on you, possibly losing state while doing so, and also having the data modified at any point because other processes can also change the state. What you’ve effectively created is something like a reference to the state you want to work with. Sure, when you have it in your hand you can trust that it’s the same state you got from the KV process, but you can never trust that you have the “correct” data in the sense that it’s the updated one.
The BEAM is great in that your particular piece of memory that holds the data you have can’t be changed by anything else, so that’s great, but putting too many things in processes and calling stateful functions with them will still invite harder debugging.
If you had a function that modified the map and then passed that map to the function as an argument everything that that function relies on is inside that function. It doesn’t make any assumptions about the world; for example that a KV store is running somewhere.
It’s trivial to emulate stateful constructs in Elixir, but we generally never set out to do so unless it’s really needed. The point is to make the least amount of assumptions possible about what exists when you run something. The ideal is for everything that a function touches to be something it’s given up-front.
The possible issue is that you’re not necessarily asserting that it should be a list if you ended up using only values, yeah. I prefer code to be as assertive as possible about structure and constants if possible. If something in the function itself makes the assumption that lists are passed in, we should try to make things that don’t follow that crash horribly, IMO.
On a related note: I vastly prefer the structural form to is_list().
I prefer code to be as assertive as possible about structure and constants if possible. If something in the function itself makes the assumption that lists are passed in
Well the thing is there’s no value in doing this redundantly. Repo.delete_all already checks that the inputs make sense. In fact the whole function is pretty redundant because Repo.delete_all is smart enough to no-op an empty list.
In this case it might be redundant, yeah, but in the general case you’ll get better error messages if you force structural matching when appropriate, because you’ll get errors about no function clause matching, which is generally super easy to debug. It’ll force the error earlier and be less messy.
I would add that I don’t think there is any downside to being as assertive as possible anywhere.
Here is my take:
def delete_db([]) do
:ok
end
def delete_db(values) do
Repo.delete_all(values)
end
Is really Enum.any? a replacement of length?
The documentation says:
Invokes the given fun for each item in the enumerable. It stops the iteration at the first invocation that returns a truthy value. Returns true if at least one invocation returns a truthy value. Otherwise returns false.
When I read this, I would expect that values would contain true/false values and as long as one of them is true… delete from the repo? I would flag this as a code smell, no?
Enum.any?/2 might gain you a bit, but only a little. For an empty list it returns always false, so you could do Enum.any?(list, &(&1)), which will return true for any non-empty list that does not consists of only nils and falses. But if you expect to have a list that might consit only of those, you can extend the filter: Enum.any?(list, &(&1 or (&1 == false) or (&1 == nil))) (untested).
But to be honest, I’d prefer to use Enum.empty?/1, but only if you can’t use a pattern match.
Was hoping somebody had posted this method - too often the beauty of pattern matching in function heads is forgotten! 
This topic made me realize that I need to work more on retraining my mind to see multiple function clauses not as overloaded functions but as distinct parts of one single function.
Edit: Sorry meant to be a general remark, not a specific reply.
© Copyright Elixir Forum | Terms | Privacy & Cookies
