Dave/I propose, or you should abandon it altogether in favor of an actual message based contract, like Joe proposes
I'm with the second point here. A full abstraction hides async'ness of the system
But here is the catch, we can’t use any message contract for a GenServer because the call/cast messages it uses are private/opaque! Which brings us back to our original point.
This is why I think eventually GenServer will have to be abandoned for more insight to messages passed
We can be more precise if we use a state machine:
open x closed -> Handle x opened
read x opened -> {ok,Data} x opened | eof x closed
close x Handle -> ok x closed
protocol is more than an api, e.g. encapsulates state of messages that have gone before
Most of this post was just thinking out loud - more about state machines for describing APIs is in the appendix of my PhD thesis it’s a system called UBF.
https://elixirforum.com/t/should-we-adopt-daves-way-of-building-applications-as-a-series-of-components-daves-talk-has-now-been-added/14428/88
I'm with the second point here. A full abstraction hides async'ness of the system
This is why I think eventually GenServer will have to be abandoned for more insight to messages passed
open x closed -> Handle x opened read x opened -> {ok,Data} x opened | eof x closed close x Handle -> ok x closed
protocol is more than an api, e.g. encapsulates state of messages that have gone before
This should be on my to read list