I think even something similar like "all_with_match/3" or "all_by_match/3" makes this less awkward than "all_match/3".
> We can add a stream_all/1 in the future if necessary. On this note, wouldn't it make more sense to start with stream implementation directly? It seems to be a lower abstraction than the concatenated list and the list is just an "Enum.to_list/1" call away for users. Andrea Leopardi [email protected] On Wed, Apr 17, 2019 at 9:56 AM José Valim <[email protected]> wrote: > I agree. Let's go ahead with what you have originally proposed. In case of > multiple partitions, we will simply concatenate the results. We will add a > note that it is potentially expensive on duplicate registries with multiple > partitions. We can add a stream_all/1 in the future if necessary. > > My only last question is about the function name. Registry.all/1 makes > sense but if we want to add a version that also supports match specs, then > we would need to add Registry.all_match/3, if we are to keep the current > convention. But I think "all_match/3" is a bit awkward? Any further > thoughts on the name? > > Note Registry.match/4 already exists and it performs a match under a given > key. > > *José Valim* > www.plataformatec.com.br > Skype: jv.ptec > Founder and Director of R&D > > > On Wed, Apr 17, 2019 at 9:44 AM <[email protected]> wrote: > >> I understand the value of implementing it the way `Registry.dispatch` >> works, but it makes using it a bit awkward. In the example use case I gave >> earlier, it would look something like this in the coordinating process >> >> ``` >> handle_info(:interval, state) do >> new_keys = get_keys_from_external() >> Registry.all(registry, fn entries -> >> current_keys = Enum.map(entries, &(elem(&1, 0)) >> synchronize(current_keys, new_keys) >> end) >> end >> ``` >> >> Which is okay, I guess, but the data is stuck in the callback. Also, if >> we copy the way that dispatch handles partitions the code would only work >> if there aren't multiple partitions. Not sure how I'd go about collecting >> the entries from multiple partitions, maybe in an ETS table? Sending to >> myself and storing in state? Either way, it's not very ergonomic. Maybe I'm >> missing an obvious solution. >> >> Would it make sense to implement it as a Stream? It should provide some >> of the same properties as the dispatch solution. We could iterate over the >> tables and handle partitions seamlessly. >> >> -- >> 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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/503ef13f-9e18-4e64-8e1c-84ca677ab504%40googlegroups.com >> . >> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JO%3DjveXLf5RHyGqsnNVnjpLW1%2BsDV%2BHpRv8LD9ZwWkkw%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JO%3DjveXLf5RHyGqsnNVnjpLW1%2BsDV%2BHpRv8LD9ZwWkkw%40mail.gmail.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAM9Rf%2BJRgOQxyKrWNRMsnnG7jd%2BgLz0ntiKee6me6-s5yShysA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
