api: add ApplicationHandler::as_any
#3851
Conversation
This could be used to subscribe for custom events.
|
Example on how to use it #3852 |
| /// Get the [`ApplicationHandler`] as mutable [`Any`]. | ||
| /// | ||
| /// This is required to be implemented when platform specific traits are desired. | ||
| #[inline(always)] | ||
| fn as_any(&mut self) -> Option<&mut dyn Any> { | ||
| None | ||
| } |
There was a problem hiding this comment.
I played around a bit to figure out how we can get rid of this:
daxpedda@3740148
Mostly inspired by upcast.
I'm warming up to the VTable idea, but I couldn't find any documentation on how stable this is, so I'm unsure what the proposal around this was exactly.
There was a problem hiding this comment.
I'm warming up to the VTable idea, but I couldn't find any documentation on how stable this is, so I'm unsure what the proposal around this was exactly.
vtable is only for completely out of tree stuff, for regular staff you don't need vtables, since users will have Option<dyn Handler> and you can just if let it. But function pointers are completely safe and stable, there's nothing wrong with them and they are all completely safe code.
it's just in the current state of things I decided with vtable, since it won't affect other APIs and for entirely platform specific staff I'd use this approach unless we have separate crates.
We can have -> Option<&mut dyn MacOSApplicationHandler> from the ApplicationHandler itself already, and it's vtable free.
There was a problem hiding this comment.
Yeah okay, I was thinking of totally different things.
I would like to avoid having to use register_x() entirely. That is possible by unsafely reading the VTable and figuring out at runtime if a trait is implemented for a certain type.
|
This is already present on master. |
This could be used to subscribe for custom events.