From ba996ddb3a3a49065d26ff1010790b17bc8709ec Mon Sep 17 00:00:00 2001 From: Julian Eisel Date: Thu, 11 Mar 2021 13:47:16 +0100 Subject: Cleanup: Add comment explaining plan for new Outliner tree-element code design Explains how we can get rid of implicit assumptions and `void *` arguments/storage in the future. --- source/blender/editors/space_outliner/tree/tree_element.cc | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) (limited to 'source/blender/editors') diff --git a/source/blender/editors/space_outliner/tree/tree_element.cc b/source/blender/editors/space_outliner/tree/tree_element.cc index d537bdfc99c..6fe3f341fd3 100644 --- a/source/blender/editors/space_outliner/tree/tree_element.cc +++ b/source/blender/editors/space_outliner/tree/tree_element.cc @@ -37,10 +37,20 @@ namespace blender::ed::outliner { static AbstractTreeElement *tree_element_create(int type, TreeElement &legacy_te, void *idv) { - /* Would be nice to get rid of void * here, can we somehow expect the right type right away? - * Perfect forwarding maybe, once the API is C++ only? */ ID &id = *static_cast(idv); + /* + * The following calls make an implicit assumption about what data was passed to the `idv` + * argument of #outliner_add_element(). The old code does this already, here we just centralize + * it as much as possible for now. Would be nice to entirely get rid of that, no more `void *`. + * + * Once #outliner_add_element() is sufficiently simplified, it should be replaced by a C++ call. + * It could take the derived type as template paramenter (e.g. #TreeElementAnimData) and use C++ + * perfect forwarding to pass any data to the type's constructor. + * If general Outliner code wants to access the data, they can query that through the derived + * element type then. There's no need for `void *` anymore then. + */ + switch (type) { case TSE_SOME_ID: return TreeElementID::createFromID(legacy_te, id); -- cgit v1.2.3