-
Notifications
You must be signed in to change notification settings - Fork 63
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ETS table rendering to Kino.Process.{sup_tree,app_tree} #430
Comments
This looks nice! Two questions:
You can also try it out in a |
Thanks!
|
I would invert the arrow then (perhaps annotate it with (heir) if possible.
That would be the idea but I am not sure if it is better in practice. |
Sounds good. I'll put together a couple hard coded mocks and post them here with which route we want to go. |
I think the original one is less cluttered. I would only add an arrow to heir, but pointing to the process instead. What are your thoughts? Any thoughts @hugobarauna? |
Agree, without subgraphs.
From an educational point of view, maybe adding both "heir" and "owner" labels is a good direction. For example, before that discussion, I didn't know an ETS table could have a relationship with two processes; I thought it was only related to one process. I just learned about the "heir" thing. So, for someone like me (who is learning about ETS), if the diagram shows both labels, it can help me understand that an ETS table can have a relationship with two processes, one of which is the owner and the other the heir. I'd keep both labels. Regarding the arrows, the supervision diagram the way it is already has some implied semantics:
So, maybe we should use a different line from those two to imply a new semantic. Maybe just a simple line without arrows but with the "owner" or "heir" label. |
Sorry, I was not clear. What I meant to say is that I would add an arrow to heir in addition to the label. We should have arrows and labels in both. The reason I like the arrow in the heir case is because the "inheritance" happens by literally sending a message which transfers the table to the heir. But before the owner dies, nothing ever happens. The arrow in ownership is also important to say who owns who. For someone who is new, those relationships may not be clear, so I would emphasize them with arrows. |
Sorry, the heir is from the table to the process. Everything else is perfect. :) Should we make the display of ETS tables opt-in or opt-out? Probably opt-in to avoid initial clutter? |
Sounds good. Pretty sure I have everything as discussed in PR #432 |
Closing this as #432 was merged. |
While working on the Elixir Patterns book I found it useful to include ETS tables in the
Kino.Process.sup_tree/1
rendering so readers could see the layout of process as well as any ETS tables associated with those processes. Something like so:If there is interest in adding this to Kino I can open up a PR with my work :).
The text was updated successfully, but these errors were encountered: