I have bumped the version to 0.2.0. This version removes whereis/2 in favor of lookup/2. The new lookup/2 function works on both unique and duplicate registries.
put_info/3 and update/3 have also been added. *José Valim* www.plataformatec.com.br Skype: jv.ptec Founder and Director of R&D On Wed, Oct 26, 2016 at 5:12 PM, Chris Keele <d...@chriskeele.com> wrote: > > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/08f13768-4b85-43d9-816f-dffd0951854c%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAGnRm4Ku1Ygr_cOusLeaS-BNa6TR_FABvcQ3mEqfn9Sk3SyPmw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
