❔ Events vs Tasks
In what situation would you use an Event over a Task that might wrap the event? As an example:
vs
The second implementation is (obviously, to me) cleaner and easier to understand, all the logic together and with its vars staying in scope, for the situations where a process relies on multiple events.
Are there any memory or performance concerns with doing it that way? Or other good reasons to not do that (Assuming I am just wrapping a basic Event with a TaskCompletionSource that's handled somewhere else) (And assuming I'm using async Events correctly, which I haven't really looked into how to do them without async voiding but I assume it's possible...)
Are there any memory or performance concerns with doing it that way? Or other good reasons to not do that (Assuming I am just wrapping a basic Event with a TaskCompletionSource that's handled somewhere else) (And assuming I'm using async Events correctly, which I haven't really looked into how to do them without async voiding but I assume it's possible...)
4 Replies
tasks are essentially one time event handlers
good for stateful workflows
for housekeeping, like e.g. counters in a game, events work better
wrapping an event in a task is a good idea
the other direction feels weird to me
performance? I don't think so really
a task completion source is just a tad bit more housekeeping
The question is mostly about defining those two different situations, when events are appropriate over tasks. Because... why not make both, use whichever one makes the most sense
yeah, make both, sure
as long as it helps simplify your logic, make both
.
Was this issue resolved? If so, run
/close
- otherwise I will mark this as stale and this post will be archived until there is new activity.