The amount of inherited functions is very large, usability problem.

[BMaxV]

Description

calling dir() on https://docs.panda3d.org/1.10/python/reference/direct.showbase.ShowBase#direct.showbase.ShowBase.ShowBase.camera returns a list of 792 methods. I tried this with DirectLabel in the first place and the number of functions in that is 889. I find a list that long hard to navigate.

This is not a topic I expect any "progress" or action on, I just want to mention it here and leave it up for debate.

I realize this may be a "me" issue in the sense that there are methods and tools to handle this complexity and other people are using those tools and I'm not and that is the problem. Int hat case it would be cool if those tools and how to set them up could be documented. Even some "I'm using [software] and that helps me" would be great.

Maybe it is a programming issue, maybe it isn't. Maybe it is because of some of the C++ parts like 'hasColorScale','is_hidden','setTexRotate'. Which in python might be just properties that can be set and C++ requires getter/setter functions? In that case maybe something can be done with the to python conversion?

In any case, those don't apply to "camera". In case of text or directlabel, there could be an argument here, but maybe that could be done via composition by the user? I'm assuming there is some automation is involved during building and it's a byproduct of that.

So what I'm saying, if there were a big design change upcoming that could touch this, maybe think about doing something about it.

I'm expecting this to be not a priority and probably a "won't fix", but it would be great if we could leave it up as an open issue.

Use Case

Easier usability.

[serkkz]

Usually, ShowBase is not what you need to explore, it is a common template for creating an application. Also, if you are directly interested in camera methods, then there is a structured API for this.

https://docs.panda3d.org/1.10/python/reference/panda3d.core.Camera

[BMaxV]

Even that core object still has 434 methods, and it is also doing things like 'getNestedVertices'.

I feel like there is an implicit, undocumented design philosophy at work that I'm not getting, which would be good to know for developing with panda.

[serkkz]

This is the PandaNode method

Camera > LensNode > PandaNode

https://docs.panda3d.org/1.10/python/reference/panda3d.core.PandaNode#panda3d.core.PandaNode.getNestedVertices

[WMOkiishi]

On a C++ wrapper class, about half of those methods will just be camel-case aliases for other methods. Those will probably be removed in 2.0.

[ArsThaumaturgis]

One thing that might be worth mentioning regarding "Camera", specifically, is that at its core it's... just a node in the scene-graph, like any other. It can be moved, scaled, rotated, reparented, and so on and so forth. Hence it has access to all of the methods of a node in the scene-graph, even if in some cases those have little effect or return only basic data.

This also means that one might expect, when searching the scene-graph, to potentially encounter the camera--and want the standard functions and methods to still be present and operative, even if they do little. (Ideally without having to explicitly check whether the current node is a camera.)

As to using "dir"... I'm curious, if I may: why do that, rather than check the API pages? The latter would provide the methods specific to a given class, and can be followed back through its inheritance to whatever level is called for.

As for how--speaking for myself--I handle this complexity, I suppose that the answer is simply that I look for what I want, when I want it, via the API or the forums; I don't really need the majority of methods at any given time.

And furthermore, knowing (to some degree) the inheritance of a given class allows me to think about it in the manner appropriate: e.g. Given a Camera, I might adjust its lens as a Camera, move it as a PandaNode, etc.

[BMaxV]

As to using "dir"... I'm curious, if I may: why do that, rather than check the API pages?

It is easier to type dir(myobject) and running my program than opening the API, searching for the correct class name and then scrolling through the list. I generally don't have the API open when do I things. It is often too hard to navigate and not very useful. It also doesn't contain the same information as the objects themselves. It has it's upsides, like the documentation text, but it's not the first choice when I'm looking for information.

I'm not saying anything against the standard methods, it's more about everything being available from everywhere.

E.g. whether something can be be done via. [only camera.lens.method] or [camera.method or camera.lens.method or showbase.method or all of them] is a choice. I don't like the later option, and I'm wondering if there was a specific reason for it or if it just evolved to be this way.

It's not really about the camera that was just an example. Directgui objects have similar issues, but those are an easy target so I figured I shouldn't use them as an example.

[ArsThaumaturgis]

It is easier to type dir(myobject) and running my program than opening the API, searching for the correct class name and then scrolling through the list.

Interesting! I think that for me it's the opposite: I find it far more convenient to do the search and get nicely-formatted data, complete with inheritance -graphs and -links, than to parse through the text-only output of "dir".

Or I suppose that I might put it this way: it's easier to get data from "dir", but easier--to my mind--to make use of the data from the API.

Anyway, thank you for answering my question!

It's not really about the camera that was just an example.

Ah, I see!

E.g. whether something can be be done via. [only camera.lens.method] or [camera.method or camera.lens.method or showbase.method or all of them] is a choice.

Yes, I think that I see better now what you're saying.

Hmm...

I can't speak to the history of the engine--remember that its early developers are likely not around on this site these days.

I imagine that the "showbase." paradigm was simply a matter of convenience: a way of having quick-and-easy access to things that were used often and in many places (such as "render"). (And without having to pass them around as parameters to everything, or search the scene-graph, etc.)

And I daresay that similar is true of other such cases. For example, the NodePath class provides access to a number of things that are technically aspects of its contained node, I believe. But it's more convenient to access things from the NodePath--which one tends to have easy access to anyway--than by dotting every single time to reach the actual node in question.

(All of that said, some of what you highlighted isn't really related to that. For example, the "Camera" class having a method for rotating textures is, I think, primarily a consequence of the fact that cameras are scene-graph nodes in Panda; it's not a result of a proliferation of means of accessing methods, just of inheritance.)

[rdb]

I think if anything, we should have more specific issues for more specific areas to redesign, such as NodePath. NodePath is a particularly large class with many methods to mutate the state, but most of these methods are also following a general pattern and classes that inherit from it should not exist in the first place.

If you have specific ideas for a NodePath redesign, feel free to open an issue suggesting it, though I think the cost far outweighs the benefit of significantly overhauling NodePath.

The problem is already significantly reduced when we drop camelCase aliases as well as getters/setters in favour of property interfaces, because that would reduce:

node.clearName()
node.clear_name()
node.hasName()
node.has_name()
node.setName()
node.set_name()
node.getName()
node.get_name()

down to just node.name.