> Right now the word registry is highly specific to processes, that's why we didn't consider Process.Registry but we will keep it in mind. One downside for this change is that I could see a strong argument being made for Process.Supervisor (instead of Supervisor). Both are process specific after all.
This is a good point. My only thought is that Supervisor is made to be used to build others (Task.Supervisor) so stays out of the way in the top level, whereas Registry cannot be used (AFAIK) and we might want to create other kinds of Registry in the future (Module.Registry, Node.Registry, or something), so it stays out of the way by being under the Process namespace. > @voltone and others have benchmarked the registry. Those are some pretty incredible benchmarks! :o On Wednesday, October 26, 2016 at 2:37:11 AM UTC-7, José Valim wrote: > > > Is this meant to be used instead of ets? > > Generally no. However, if you need to store data that is automatically > removed when a process dies, it may be a good candidate. > > > would Process.Registry be the name of this thing when added to the > stdlib? > > That's a good question. Right now the word registry is highly specific to > processes, that's why we didn't consider Process.Registry but we will keep > it in mind. One downside for this change is that I could see a strong > argument being made for Process.Supervisor (instead of Supervisor). Both > are process specific after all. > > > Looking at docs and code, it seems that Registry suffers from a mild > case of the :supervisor syndrome :-) > > We had this in mind when discussing the registry. At this point, it is > rather a :ets syndrome: functions receive the same arguments and return the > same values although may behave slightly different depending on the > registry type. After your question, I have decided to quantify those a bit > more: > > Supervisor: > > * Functions that behave exactly the same: count_children/1, > which_children/1 > * Functions that expect same inputs/outputs but behave differently: > start_link/3 > (due to differences in the init/1 callback) > * Functions that expect different inputs/outputs: start_child/2, > terminate_child/2 > * Functions that are not supported by all types: delete_child/2, > restart_child/2 > > Registry: > > * Functions that behave exactly the same: start_link/3, dispatch/3, > keys/2, unregister/2 > * Functions that expect same inputs/outputs but behave differently: > register/3 (one type supports multiple registrations) > * Functions that expect different inputs/outputs: > * Functions that are not supported by all types: whereis/2 (which powers > :via) > > As you can see, more than half of the functions in Supervisor behave > differently depending on the type, many having different inputs/outputs or > are not supported across types. > > For the registry, we don't have functions that expect different inputs and > outputs depending on the type and a single function that is not supported > across registries. Most operations behave exactly the same, except > register/3 (which is the point of having different registries). > > Code wise there are some checks on the registry type but they are mostly > optimization. For example, the checks on dispatch/3 and keys/2 are > optimizations and could be removed by doing more work at some point. > > It is hard to know if two functionalities should be kept apart or > together. Right now, it makes sense to keep them together but this may not > be true in the future when the API surface grows. On the other hand, we > could split them and realize in 2 years that even with API additions, they > behave the same. Our best bet is to quantify how similar they are to each > other now and try to estimate what we may want from the registry in the > future. > > Furthermore, if we split it apart, I don't believe we should call it > PubSub since it isn't one (although it can be used to build one). > > Thanks everyone for the feedback so far! > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/08f13768-4b85-43d9-816f-dffd0951854c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
