Add show inherited properties and methods in API docs

[jpgmahedero]

Hello,
this is my first proposal, so maybe I'm not doing it in the proper way or place. If so, please tell me how to do it.

Coming from Phaser I found it hard to find where inherited properties were defined. I could look at the inheritance tree, but I had to do it class by class. Well, using intuition, one could save a few steps but it wasn't right away

It would be nice to have direct access in every class documentation to all of its inherited properties and methods. Maybe a list of all of them showing with a link to the classes they were defined. About formatting maybe a breadcrumb could be nice so every class int he inheritance tree would be accessible

Phaser API examples. Not very beautiful in my opinion (but it's arguable), but it is functional:

• https://newdocs.phaser.io/docs/3.60.0/Phaser.Physics.Arcade.Sprite Have a look at _alpha private member. You can see it is private and comes from Phaser.GameObjects.Components.Alpha#_alpha

thanx

[Zireael07]

Can you edit the discussion title to be more informative?

[jpgmahedero]

Sorry I just found I forgot. Done now

[AThousandShips]

This already exists, see here

For methods it's an implementation detail and I don't think it'd help to know in the documentation, it would clutter

Nite that unlike other documentation the API documentation doesn't allow modification and the API is bound, not in GDScript or C#, so the specific implementation points are not relevant details

The only relevance would be that the behaviour changes but that is happening through other ways as well so it's not reliable to just know if a method is overridden, further that information isn't even available to the API as the methods are only bound once

[jpgmahedero]

I see it useful to learn when you are a beginner. When I look at a class I don't know what its attributes may be because they are defined in higher classes in the inheritance hierarchy and I don't even know that they exist.

For example, someone who starts and finds the AnimatedSprite2D class does not know whether or not it has a property such as x or y. You don't know if its called position nor what type does it have. You have to "climb" the inheritance tree and examine each class.

Anyway you could always use a checkbox to show or not this info

[jpgmahedero]

Well, I don't think it would be that much info shown... but anyway you could use a checkbox/dropdown just to show or hide them.

[AThousandShips]

That would be a lot of extra data

You would show literally hundreds of properties in some classes

And many many more methods

Just to not have to do a very little bit of navigation, there's very few classes that have a hierarchy of more than 5-6 nodes, which isn't too much to just look through for properties and methods

[jpgmahedero]

Well, maybe hundreds of them is too much. Anyway, please have a look at this Phaser class doc (https://newdocs.phaser.io/docs/3.60.0/Phaser.GameObjects.Sprite)

It has like 100 methods and 100 properties. Most of them are not private, but its an example of how long could it be. I'm not an UI expert, but if its well structured I think it isn't that much. If there were to be more privates and you could hide/show them, it would be shorter.

As another example with a different UI approach, I don't know anything about Unity but a quick search about RigidBody (for example)showed me this:
https://docs.unity3d.com/ScriptReference/Rigidbody.html

As you said, you could still use inspector, but optionally showing all of them is faster and gives you a better understanding of the whole class structure which I think is always helpful

I think the problem is mostly UI design, which is always an arguable subject. I don't know how much work would it be for developpers implementig it (I'm really grateful to them for developing such an amazing engine). I just think it be helpful, as I think in other engines they have done, even if Godot, of course, should have its own opinion/roadmap.

[AThousandShips]

The issue is just that, adding this functionality would involve probably some significant UI work to do, there's no support for collapsible regions in the built-in help, and having a button or setting for it would also complicate things

It would also significantly increase the time taken to generate and reload help pages since the amount of information on them would grow drastically

And I think an important point is that the built-in help, and the online docs, aren't for the same reasons as a lot of online docs and API info, and doesn't include a lot of the type of info that would be relevant for working with it in a module or an extension with c++ code, where a lot of methods and stuff are accessible which aren't from GDScript

To be clear, I recognize the value of what you are asking for, but I think the gain in ease of overview is worth the work required, the performance involved, and the complexity

My reasoning:

• The inherited information is relatively easy to find, as the inheritance is rarely very deep, and if it is deep it rarely has much information at every level
• GDScript does not (at least currently, and won't at all in core I would dare to assume) allow things like interfaces, multiple inheritance, etc. meaning that said inheritance is linear
• Much of the information is information that should be known if you use the base node types regularly, (almost) everything inherits from Object, and then either from Node or Resource again most of the time, and then either Node2D, Control, or Node3D, it is a bit of learning curve but anyone using Godot for a length of time should be reasonably familiar with the interfaces of those classes

[jpgmahedero]

ok