Honestly, I am not sure if it is worth encapsulating the event as you propose compared to a receive. For example, what happens if you want to receive at least one message from two distinct pipelines? What happens if you are inside a GenServer, where any receive pattern can be harmful and handle_info should be preferred?
The main reason "assert_receive" exists is not because of the convenience, but rather the improved error message. And those scenarios are less common too (at least you are not running a test inside a GenServer). On Mon, Jan 24, 2022 at 2:50 PM Andrzej Podobiński < andrzej.podobin...@swmansion.com> wrote: > Hi, > thanks for your interest! I'm working on a specific pipeline in the > Membrane framework. The API of this pipeline allows the user to subscribe > for events that this pipeline emits, and then synchronously wait for these > events. The idea is to provide a macro that wraps the receive block to make > waiting for the event nicer to the user - just like assert_receive. > > https://github.com/membraneframework/membrane_core/blob/remote-controlled-pipeline/lib/membrane/remote_controlled/pipeline.ex#L55 > ps. I'm aware that the current implementation of "await" I've linked won't > work because of e.g. lack of macro expansion. > niedziela, 23 stycznia 2022 o 18:58:14 UTC+1 hunter...@gmail.com > napisał(a): > >> Hi, >> >> I'm wondering what sort of code you're trying to write where a receive >> ... after block wouldn't work well in this situation. Furthermore what do >> we do in the error case if the receive times out? For ExUnit this is quite >> simple: the test fails, but in your application code this doesn't mean >> anything. If you get to the point that you're specifying control from with >> this new macro then you've just recreated receive with more steps. Could >> you provide some code samples for what you're trying to achieve? >> >> Best, >> Theron >> On Thursday, January 20, 2022 at 9:22:43 AM UTC-6 >> andrzej.p...@swmansion.com wrote: >> >>> Lastly, I was trying to implement a macro with similar functionality as >>> assert_receive from ExUnit. The purpose of this macro was to allow the user >>> to wait synchronously for a message specified by a pattern. The given >>> pattern may contain variables that the user is interested to extract from >>> the arrived message (exactly as in ExUnit.assert_receive). I've noticed >>> that there is a significant amount of code that expands the given pattern >>> and then collects the variables from it etc. in order to properly extract >>> variables from the pattern. I have a feeling that it is not a valid >>> solution to use an ExUnit.assert_receive in the production code, so maybe >>> it would be possible to add the function of similar functionality to the >>> Process module. Something like Process.await_message(). Another possibly >>> better solution could be adding some functionality to the Macro module that >>> would cover expanding the macro and collecting variables etc. ( >>> https://github.com/elixir-lang/elixir/blob/a64d42f5d3cb6c32752af9d3312897e8cd5bb7ec/lib/ex_unit/lib/ex_unit/assertions.ex#L467 >>> ) >>> >>> -- > 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/86836f06-f926-42de-aed0-9576d836b61cn%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/86836f06-f926-42de-aed0-9576d836b61cn%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAGnRm4KkMx4ieSOCtBYBgfzsBuAK0Bb%2B5mseg%2BQXRs0dscOeMw%40mail.gmail.com.
