A colleague came to me with something similar to the following puzzle,
iex(9)> defmodule Record do defstruct [a: 1, b: 2, c: 3] end
iex(10)> defmodule State do defstruct [d: 4, e: 5, f: %Record{}] end
iex(13)> record1 = %State{}
%State{d: 4, e: 5, f: %Record{a: 1, b: 2, c: 3}}
iex(14)> record1 = %{record1 | f: %Record{c: 9}}
%State{d: 4, e: 5, f: %Record{a: 1, b: 2, c: 9}}
iex(15)> record2 = %{record1 | f: %Record{a: 9}}
%State{d: 4, e: 5, f: %Record{a: 9, b: 2, c: 3}}
iex(16)> record3 = %{record2 | f: %Record{c: 9}}
# problem is here… ":a" is "1" again
%State{d: 4, e: 5, f: %Record{a: 1, b: 2, c: 9}}
iex(17)> record4 = %{record3 | f: %Record{a: 9, c: 9}}
OK, stupid.
I see the problem, we are creating new records each time : )
Interesting how trying to explain a problem, also solves it : ))
I think you may be seeing the remnants of a statement based mindset. Because from the script it isn’t clear whether you actually wanted different records or whether you are simply advancing the state of the same conceptual record - for which Elixir does allow rebinding.
The script still has that imperative “do this, then do that” kind of feel (which is typical for scripts anyway but I assume that the original code looked like that as well).
I personally have no qualms having lots of well-named single line functions that also use argument pattern matching for destructuring; essentially allowing for “composed functions” (not necessarily in the FP sense and not always with the pipeline operator) so that if possible the code can look more like a progressive flow of value transformations rather than some step by step recipe.
2 Likes
yeh normally I do |>
all the way, and (luckily) never find myself in this situation…