Naming mostly (one of the reasons I’m very quick with converting anonymous functions into module functions or at least a module function that creates the anonymous function (for the benefit of the closure)). To me
Foo.get_pid(key, reg \\ Registry.SomeRegistry)
telegraphs intent of crossing the process boundary given that our own pid is available via self() and a “registry” is mentioned which typically identifies a process pid for the process that manages that information.
What would be even more helpful is a Typespec that would identify reg as a pid().
The thing is that some of the naming may be a bit subtle for a beginner - who may need to be hit with a two-by-four to get the idea - but once your mental model for OTP and process based programming has formed sufficiently it should be fairly easy to “telegraph your intent” (which I suspect @OvermindDL1 was talking about).
I am having trouble understanding what you mean by this, could you explain it in a different way?
To come at it from a different angle I can go back to the OO days of UML and CASE-tools. People often provided lots of information to assemble their static class diagrams - which can be helpful to get a sense of the static partitioning of the logic in the system especially if you are trying to hunt down some logic that you need to tweak.
By and large the class diagrams are utterly useless when you are trying to understand how the system works because that behaviour is dynamic. For that you need activity and sequence diagrams because they describe the protocols enacted between the object instances to get stuff done. Activity and sequence diagrams have a time line which sequences the “messages” as they are exchanged between the objects.
I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea.
The big idea is “messaging”
And we’re no talking about individual messages - we are talking about the “set of messages” that are exchanged between the participants to enact a protocol.
With processes it’s too easy to focus on a single process and what it does - when in fact it is necessary to observe the entire protocol over all the processes involved as the protocol unfolds (evolving protocol states of the participants) over time.
With an API it’s too easy to focus on just the available methods (or functions) - ultimately it’s more important to understand in what sequence (again passage of time) the functions have to be used to effect a desired outcome.
Watching
- Torben Hoffmann - Thinking like an Erlanger
- [Torben Hoffmann: Protocols - The Glue for Applications]
(Protocols - The Glue for Applications)
will probably give you a better idea of what I’m trying to convey.
