Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Why Event<> in the interface? #4

Open
slimshader opened this issue Jul 28, 2020 · 2 comments
Open

Why Event<> in the interface? #4

slimshader opened this issue Jul 28, 2020 · 2 comments

Comments

@slimshader
Copy link

Hi,

a question regarding design of component interfaces: why do interfaces expose Event(s) instead of explicitly declaring a method?

say why:

public interface IInteractable : IComponent
{
  Event<int> onHoverEnter {get;}
}

instead of:

public interface IInteractable : IComponent
{
  void OnHoverEnter(int arg);
}
@lazlo-bonin
Copy link
Owner

Hi!

The idea here is that an event can be both triggered from the caller (like a method), but also subscribed to.

So for example, a listener could be interested in knowing when another IInteractable was hovered, and a method does not allow this.

In the ideal world, this access control would be better — the component should be able to explicitly define whether an event can be subscribed externally, or published externally, or both. This is something I've been working on in my own private fork of GoCS for our game project and it's working quite well. Down the line, I'll probably update GoCS with this approach.

@RealityStop
Copy link

I humbly submit https://github.com/RealityStop/gocs as a stopgap until the new official version of GoCS arrives. I felt the same need for directionality in Events, so I made a few alterations.

It adds:
IEvent -- equivalent to Event, bi-directional
IEmittedEvent -- exposes add/remove listeners, output
IHandledEvent -- exposes invoke, input

Arguably, there is little benefit to the IHandledEvent over a method (Perhaps the ability to have a null event to signal that it isn't supported vs an empty no-op method or a predicate syntax).

However, IEmittedEvent is exceptionally useful, and correctly signals that the event is not listened to by the component. For me, this is desirable because they are reaction points for systems, particularly when mixed with some OOP code. In my little project, a creature's AI is running on the instance, even if the individual aspects such as movement are handled via Systems. Thus, when the creature AI directs it to (for example) enter its den, I need my Systems to be able to react to that Event. And that's a fundamentally different Event style than the regular System-dispatched (IHandledEvent) Events.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants