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

Event Context Calculators #2302

Open
ItsDoot opened this issue Mar 3, 2021 · 3 comments
Open

Event Context Calculators #2302

ItsDoot opened this issue Mar 3, 2021 · 3 comments
Assignees
Labels
api: 8 (u) version: 1.16 (unsupported since Oct 17th 2023) system: event type: feature request A feature request

Comments

@ItsDoot
Copy link
Member

ItsDoot commented Mar 3, 2021

In the same vein of how permission context calculators work, event context calculators would automatically add EventContextKeys to an event's context.

A rough outline:

@FunctionalInterface
public interface EventContextCalculator<T> {
    Optional<T> calculate(Cause currentCause, EventContext currentContext);
}

public interface EventManager {
    // ...
    <T> void registerCalculator(TypeToken<? extends Event> eventType, EventContextKey<T> key, EventContextCalculator<T> calculator);
    // ...
}
@limbo-app limbo-app added the status: needs triage This label is automatically applied to new issues and pull requests to indicate they require triage label Mar 3, 2021
@gabizou
Copy link
Member

gabizou commented Mar 3, 2021

So, this is something along the lines that I'm thinking of:

public interface EventManager {
  <T, E extends Event> void registerCalculator(TypeToken<E> token, EventContextSupplier<T> supplier);
}
public interface EventContextSupplier<T> {
  EventContextKey<T> key();
  // Cause has an  accessor for the context, so you can freely take a context from the existing cause.
  // And ultimately, a predicate is just a matter of returning an empty optional.
  Function<Cause, Optional<T>> calculator();
}

@dualspiral
Copy link
Contributor

Why would you want calculator be a Function, rather than just the function itself?

@gabizou
Copy link
Member

gabizou commented Mar 4, 2021

I'm debating on whether a function "needs to be called" versus something that can be broken down to predicates, potentially thinking of the possibility of slight exposure to the Object being the current root, without having to construct a Cause for the function, (half way to a PhaseState + Context). This being a possible workaround to the Object being typed, or providing a frame to populate based on the Object source (or some Cause that isn't completely constructed as Cause is currently, or possibly a Cause that is passed to each of the calculators to avoid a priority-by-registration-order bias).

@ImMorpheus ImMorpheus added api: 8 (u) version: 1.16 (unsupported since Oct 17th 2023) system: event type: feature request A feature request and removed status: needs triage This label is automatically applied to new issues and pull requests to indicate they require triage labels Apr 4, 2021
@gabizou gabizou self-assigned this Jul 28, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
api: 8 (u) version: 1.16 (unsupported since Oct 17th 2023) system: event type: feature request A feature request
Projects
None yet
Development

No branches or pull requests

5 participants