Documentation Request: Inheritance View in Overviews

The above link in the listing of all of the container classes within the Core module. It’s a decent sized list that enumerates all of the container types provided by the engine, however, there is no organization other than alphabetical in that list. I would like to suggest that in the overviews of a module (the index pages), such as the one above and the below examples, that a hierarchy list be set up that shows which classes are related to each other through inheritance (Instead of just being apparent when you actually choose a specific class to view):

In addition to that I would like to suggest that there be a check box at the top of class documentation pages that allows you to toggle whether or not to show function and variables that have been inherited from their parents, those could then be shown in sub-categories. For instance in the class view we have categories like Variables and Functions, perhaps when toggled there would also be further subcategories in those sections, like in TMap we could have the class’s functions then in a subcategory under Functions we could have the functions from TSortableMapBase and then in another subcategory the functions from TMapBase, that way everything can be presented to the viewer on the exact same page, instead of having the information be spread across multiple pages.

There is already a hierarchy view:

Showing inherited members should be possible, but I would be worried about cluttering up every page with duplicated information. The amount of inherited members would grow very quickly as you move down the hierarchy. We can consider it though.

Unfortunately that page isn’t any better than just moving directly to the classes in the index page, since it has EVERYTHING. The result being that the page is basically worthless in most cases, since you only want it if you want to peruse the entirety of the engine. If you know what class you want to look at then you jump directly to the class page to see its inheritance, you don’t go to that page. That list also doesn’t help when you want to see how a particular module is modeled, by any means, and once again that list is particularly unuseful since once more its organized not by a logical structure such as by module, or even by something more nebulous like “usefulness”, but rather by alphabetical order.

If I want to look at containers I don’t want to look at everything else, I want to see the containers and their particular inheritance patterns, if I want to see the structure of the Game Framework that link is worthless to me since I would have near a thousand different classes and I would have already had to have know the root of each of the the classes I was wanting to look at, however if that page had the ability to narrow down to a particular module or group of classes then the page would be more useful. However, why not just put that information in a reasonable place where everyone looking at that particular module would be able to quickly see the inheritance of the module, why split up information that would help people understand the engine structure across multiple pages? Especially when one of those pages is a titan of a list with the weakest of organization.

I was suggesting that on the index page you place a inheritance list that shows each of the classes in the module and their hierarchical connections, similar to what you already do on the specific class page.

I would also suggest that your second point is why there should be a checkbox and why by default it would probably be best to have the checkbox set to false (don’t show). Oh and a little nuance you would want to track and subsequently hide the members that have been overridden by the current class, and overridden members should show up only in the parent closest to the current class.
So if the inheritance is such: Root > Children > Grandchild > Great Grandchild and both child and grandchild override the same function then on the Great Grandchild page either the grandchild and root’s function shouldn’t appear or should be clearly marked as overridden.

I misunderstood what you were wanting. It makes sense. I’ll see if it’s something we can add. Seems like the data is all there already so it should be possible.

Glad to hear that, looking forward to the revamped C++ documentation too.