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.

Sign up for GitHub

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

Jump to bottom

api: add ApplicationHandler::as_any #3851

Closed
wants to merge 1 commit into from
Closed

api: add ApplicationHandler::as_any #3851

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 20 additions & 0 deletions src/application.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,7 @@
//! End user application handling.

use std::any::Any;

use crate::event::{DeviceEvent, DeviceId, StartCause, WindowEvent};
use crate::event_loop::ActiveEventLoop;
use crate::window::WindowId;
Expand Down Expand Up @@ -325,6 +327,14 @@ pub trait ApplicationHandler {
fn memory_warning(&mut self, event_loop: &dyn ActiveEventLoop) {
let _ = event_loop;
}

/// 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
}
Comment on lines +331 to +337
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

@kchibisov kchibisov Aug 10, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

}

#[deny(clippy::missing_trait_methods)]
Expand Down Expand Up @@ -393,6 +403,11 @@ impl<A: ?Sized + ApplicationHandler> ApplicationHandler for &mut A {
fn memory_warning(&mut self, event_loop: &dyn ActiveEventLoop) {
(**self).memory_warning(event_loop);
}

#[inline(always)]
fn as_any(&mut self) -> Option<&mut dyn Any> {
(**self).as_any()
}
}

#[deny(clippy::missing_trait_methods)]
Expand Down Expand Up @@ -461,4 +476,9 @@ impl<A: ?Sized + ApplicationHandler> ApplicationHandler for Box<A> {
fn memory_warning(&mut self, event_loop: &dyn ActiveEventLoop) {
(**self).memory_warning(event_loop);
}

#[inline(always)]
fn as_any(&mut self) -> Option<&mut dyn Any> {
(**self).as_any()
}
}
Loading