Hey! I really appreciate the feedback!
If I understand the idea correctly, we’d still need to traverse the process tree and do a Registry lookup for each process? Process.info/2 is indeed expensive, but it’s only done once per process, so the cost should be neglectible, since Vault is cached locally afterwards, and subsequent lookups are cheap.
The whole point was to make this data immutable, for ease of reasoning about it. Maybe it’s not an ideal assumption? I didn’t want to break FP purity patterns too much here.
I’m not sure if it’s needed, assuming we’re propagating the state to the bottom only. What will be a typical use-case for that?
Easy to remember name, a little implying immutability “guarantees” of the data being stored in there.
This won’t happen, since Process C won’t be able to initialize its vault, because Process B already did. And we have a loose guarantee (excluding dynamic links and creations) for at most one vault per connected components. This might be too restrictive, since we’re not only traversing children, but all connections.
Using $ancestors + $callers + :erlang.process_info(self(), :parent) as a list of associated processes should resolve both of these issues, since they’ll have a tree structure, and for a subtree - we’ll have a guarantee for a single vault.
Overall, I wouldn’t use the library in it’s current state, but idea to have some storage which is accessible by direct children of the process is pretty good. If I were to solve this problem, I would use
$callersand$ancestorswith Registry entry.
Can you elaborate more on why you see registry fit better here? I’m not seeing any clear benefits as for now, but I’m most likely missing something?
And about GraphQL, I had a very similar problem and I just passed the user explicitly. Even if I have to pass it into 8 functions deep, I would just type 8 extra words, which is not a big deal, since explicit argument pays off in readability when compared to semi-global semi-mutable storage
Actually, in relatively complex systems that are already built - this quickly became an issue when we needed to introduce audit logs with an actor. Places, where previously we didn’t have access to the user needed to have it, and there was no easy way to refactor all these functions to introduce another argument.
and I think we should be fine with not placing any expectations there? I’m open to any alternatives though