-
-
Notifications
You must be signed in to change notification settings - Fork 235
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
What's the purpose of EventId? #1070
Comments
The EventId makes it possible to add custom events on top of When somebody needs a different structure they often represent it differently in memory. The lambda based functions makes it possible to use the event without overhead, for example Since In earlier days We changed away from Later when we redesigned, we replaced it with |
Coooool. Thanks for the response! A follow up question, then: Since the Input event type can be specified by an implementation of Window, why not make the extension point for events there? So instead of using myengine/event with GenericEvent, you'd create an enum that'd look like this:
And then your match code would look like this:
Backends would have to implement some extra functions to make InputSplitter compliant with the traits that the Piston API expects, but it should all be small enough to be inlined. And it keeps the strong type-safety of the rust compiler intact. Code that uses piston wouldn't be able to define events, but that's undesirable anyway because this event system is for backend code. Is there anything wrong with this idea? |
When you write generic code, you have to use a trait. Let's say you have an event fn event<T: Foo>(e: &T) {
sub_event(e)
}
fn event<T: Foo>(e: &T) {
...
} The problem is when you introduce a new trait fn event<T: Foo + Bar>(e: &T) {
sub_event(e)
}
fn event<T: Foo + Bar>(e: &T) {
...
} This is not really back-end related, but for the whole ecosystem that depends on the library that defines the traits. All event traits in Piston are implemented for all types that implements impl<T: GenericEvent> CursorEvent for T {
...
} So, people write: use piston::input::CursorEvent;
...
if let Some(args) = e.cursor_args() {
} It is simple and less to type because the Piston core or the back-end does the matching for you. If there is a breaking change in how Let's assume that one engine adds a custom event which is really nice feature to use in generic libraries. The engine can then define an event trait for its own use, but other people who write generic libraries can just copy/paste the event trait to make it work. They don't have to use the same trait, just
|
Thanks for the detailed explanation! I get it now. |
The only time the internals of piston use it, is when writing functions to support applying lambdas if the event is of a particular type. This functionality can be reproduced using only enumerations. EventId is never used by any piston backend, and I can't find a single repo that uses the type, nor can I find any that use the lambda-based functions.
If there's no specific reason for having it, it should be removed, because it makes the event code more verbose and more difficult to understand.
The text was updated successfully, but these errors were encountered: