`Event` trait should not be reused for observers and buffered events

[alice-i-cecile]

What problem does this solve or what need does it fill?

While the Event trait is required for both observers and buffered events, it's very uncommon to use a single event type as both an observer and a buffered event.
These are used differently and have distinct semantics, despite both representing .

This makes the API more challenging to understand, opens users up to footguns where they create EventReaders for observer events or send buffered events via targeting, and also causes false positives for potential linting tools that attempt to check for things like "all Event types should have a add_event call".

What solution would you like?

Split the trait, keeping the Event trait name for buffered events, and Signal for observer events.

What alternative(s) have you considered?

We could consider unifying the underlying implementations in some way, to allow for users to seamlessly choose between them. That would entail:

1. Replicating all observer-events to buffered-events, which discards the information about what entity was targeted.
2. Automatically sending all buffered-events to observers, targeting nothing.

I don't think that this is particularly useful or clear, and has a non-trivial performance overhead. Given that I haven't seen users asking for this, and it can be easily manually implemented if it is desired, I don't think this is the right call.

Additional context

I advocated for adding a marker trait for observer events here. Much bikeshedding followed.

The unification was eventually completed by @cart in #10839 (comment), per #10839 (comment).

I think we should try to unify Event and Trigger with the intent to (ultimately) make normal "buffered" events triggerable.

IMO this change didn't get appropriate consideration due to the extreme length and complexity of that PR and should be reverted :)

[alice-i-cecile]

@james-j-obrien is in favor of this change.

[aecsocket]

I agree with separating Event and Signal, mostly because the fact that events are "push" and signals are "pull" is such a critical difference in usage, I can't see a way to paper over it.

When reacting to a signal, it's possible to mutate the signal itself and give some info back to the caller who triggered the signal (see World::trigger_ref). When reacting to an event, the caller/event writer is already finished, and there's no real ergonomic way to send some context back to the event writer. They represent two different ways of thinking, and I don't see any benefit in pretending that they're the same.

[alice-i-cecile]

@NthTensor suggests Event and Message, which is nice if we don't want to conflate observers with reactivity in the way that Signal does.

A two-by-two grid of Message/Feed + Event/Observer is also popular!

[bushrat011899]

I know bike-shedding is rather pointless, but I'm personally drawn to the idea of calling an Observer event an Observation. I think it'd help with discoverability in documentation, and it very clearly ties the two concepts together. Having said that, the idea of reworking buffered events into something more message-queuing themed could be nice (feed.publish(message), for message in feed.read() { ... }, etc.).

[simbleau]

+1 to Signal/Observation. Any progress on this? It's an footgun that continues to exist.

[NthTensor]

This is strongly desired but no one has stepped forward to do the implementation yet.