From f301738bf482b79b6e488008d1d935b11f2e032c Mon Sep 17 00:00:00 2001 From: Michele Caini Date: Tue, 18 Feb 2025 09:09:52 +0100 Subject: [PATCH] doc: rollback changes about component_traits --- docs/md/entity.md | 17 ++++++++--------- docs/md/faq.md | 2 +- 2 files changed, 9 insertions(+), 10 deletions(-) diff --git a/docs/md/entity.md b/docs/md/entity.md index 6a1739f3b..047f5c04b 100644 --- a/docs/md/entity.md +++ b/docs/md/entity.md @@ -1300,12 +1300,11 @@ packed and maximize performance, unless full pointer stability is enabled. In `EnTT`, almost everything is customizable. Pools are no exception.
In this case, the _standardized_ way to access all component properties is the -`component_traits_deprecated` class. +`component_traits` class. Various parts of the library access component properties through this class. It makes it possible to use any type as a component, as long as its specialization -of `component_traits_deprecated` implements all the required -functionalities.
+of `component_traits` implements all the required functionalities.
The non-specialized version of this class contains the following members: * `in_place_delete`: `Type::in_place_delete` if present, true for non-movable @@ -1325,8 +1324,8 @@ struct transform { }; ``` -The `component_traits_deprecated` class template takes care of _extracting_ the -properties from the supplied type.
+The `component_traits` class template takes care of _extracting_ the properties +from the supplied type.
Plus, it's _sfinae-friendly_ and also supports feature-based specializations. ## Empty type optimization @@ -1350,8 +1349,8 @@ More in general, none of the feature offered by the library is affected, but for the ones that require to return actual instances.
This optimization is disabled by defining the `ENTT_NO_ETO` macro. In this case, empty types are treated like all other types. Setting a page size at component -level via the `component_traits_deprecated` class template is another way to -disable this optimization selectively rather than globally. +level via the `component_traits` class template is another way to disable this +optimization selectively rather than globally. ## Void storage @@ -1458,8 +1457,8 @@ In other words, pointer stability is not automatic but is enabled on request. The library offers out of the box support for in-place deletion, thus offering storage with completely stable pointers. This is achieved by specializing the -`component_traits_deprecated` class or by adding the required properties to the -component definition when needed.
+`component_traits` class or by adding the required properties to the component +definition when needed.
Views and groups adapt accordingly when they detect a storage with a different deletion policy than the default. In particular: diff --git a/docs/md/faq.md b/docs/md/faq.md index 8513f7a97..d3a7d593f 100644 --- a/docs/md/faq.md +++ b/docs/md/faq.md @@ -77,7 +77,7 @@ In addition, `EnTT` also offers the possibility to create stable storage types and therefore have pointer stability for one, all or some components. This is by far the most convenient solution when it comes to creating hierarchies and whatnot. See the documentation for the ECS part of the library and in particular -what concerns the `component_traits_deprecated` class for further details. +what concerns the `component_traits` class for further details. ## Custom entity identifiers: yay or nay?