@Eiji true, you could define a generic module that could handle this, however …
With the same argument you would remove all of the shortcut syntax and only have fully qualified function names (no sigels, no `[..|..], …).
Even though it might be worthwhile to have those functions for newbies, it would be very cumbersome for those common cases.
Yes and no. Look that depending on how you write the code it may be less obvious:
user_input
|> Code.eval_string()
|> then(fn {struct, _bindings} -> struct end)
|> then(&apply(SomeModule, :update, [&1])
This way all compilers and tools would have to parse every string to support it and I guess there are much more cases that makes things like that complex.
Sigils are macros and that’s off-topic.
We have a functions for them and they’re called hd(list) and tl(list). Both could be used in pattern-matching instead of syntax notation. [head | tail] notation is for a List and not a sub-type (like structs are for maps), so it’s not the best example here.
Look that by default every struct does not implement access behaviour and there are hex packages to fix that and I wanted to propose something exactly like that i.e. extend the specific struct with the functions that are known well from a Map module (like merge, put or update), but with a help of metaprogramming we can make them more helpful for LSP user, so that the editor could propose the keys based on the oldest known patterns in the language like pattern-matching and spec.
From a credo user perspective this also reduces module dependencies, so that your module does not depend on Map and MyStruct, but only MyStruct. The code is still clear and we don’t lose any editor features.
Slightly off topic, but personally I believe the best practice is to have all structure mutations encapsulated in the respective functions and then invoke those functions from outside of the structure module (instead of updating the structure directly), e.g
ideally:
defmodule Foo do
defstruct [ :a, :b]
def update_a( foo, updater) do
Map.update!( foo, :a, updater)
end
def update_b( foo, updater) do
Map.update!( foo, :b, updater)
end
end
or at least
defmodule Foo do
defstruct [ :a, :b]
def update( foo, field, updater) do
Map.update!( foo, field, updater)
end
def update( foo, changes) do
Map.merge( foo, changes)
end
end
This approach enables far easier and less error prone refactoring and debugging as well as having the abstraction in question have the last say on validating the mutation intent.
My 2c
This only gives readability. I made one step forward in my example. The pattern-matching in function heads and specifications should be more than enough for LSP and other tools to make autocomplete working. This is very easy solution and gives people more opportunity to care about docs and specs.
Couldn’t the type system catch this bug without the pattern match, inferring from the update syntax that user is %User{}?
100% agreed
Unfortunately not in all scenarios. In this particular example yes, it would, but once you add conditionals and other constructs, it gets blurrier. Here is an example of a warning that would not be caught with the current inference but would with pattern matching:
def absolute_z(condition, point) do
point.w
if condition do
%Point{point | z: abs(point.z)}
else
point
end
end
Any conditional is problematic because we can only assume that point is a %Point{} in a specific branch, so we cannot propagate the inference up. If we assumed it to be a Point on all branches, it could lead to false positives. If you do %Point{} = point, it always works.
Also people sometimes tends to overuse some patterns like binding different values to the “same” variable.
user = struct(User, user)
# instead of
user = struct(User, user_params)
It’s the same when we pattern match in the if branch:
def absolute_z(condition, point) do
point.w
if condition do
%Point{} = point
%{point | z: abs(point.z)}
else
point
end
end
but I get the point
This made me think that pattern matching inside a branch (actually after the first usage of a variable in the scope) should be warned for variables from the outer scope in the same way struct updates are warned.
I am positive this is doable.