Nested Updates

Questions / Help
1

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 : ))

3

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
4

yeh normally I do |> all the way, and (luckily) never find myself in this situation…