-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Closed
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-MacrosCode that generates Rust codeCode that generates Rust codeD-TrivialNice and easy! A great choice to get started with BevyNice and easy! A great choice to get started with BevyS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!
Description
What problem does this solve or what need does it fill?
It would be nice if this common pattern could be expressed more easily:
#[derive(Component]
#[component(on_add = Self::on_add, on_remove = Self::on_remove)]
struct TilePosition {
x: u32,
y: u32,
}
impl TilePosition {
fn on_add(mut world: DeferredWorld, context: HookContext) {
}
fn on_remove(mut world: DeferredWorld, context: HookContext) {
}
}What solution would you like?
The component hook derive attributes currently have no default value. I propose that we default #[component(on_add)] to #[component(on_add = Self::on_add)]. For example:
#[derive(Component]
#[component(on_add)]
struct TilePosition {
x: u32,
y: u32,
}
impl TilePosition {
fn on_add(mut world: DeferredWorld, context: HookContext) {
}
}ItsDoot, Diddykonga, cBournhonesque, alice-i-cecile, MalekiRe and 6 more
Metadata
Metadata
Assignees
Labels
A-ECSEntities, components, systems, and eventsEntities, components, systems, and eventsC-FeatureA new feature, making something new possibleA new feature, making something new possibleD-MacrosCode that generates Rust codeCode that generates Rust codeD-TrivialNice and easy! A great choice to get started with BevyNice and easy! A great choice to get started with BevyS-Ready-For-ImplementationThis issue is ready for an implementation PR. Go for it!This issue is ready for an implementation PR. Go for it!