You know that I won’t stay out of the discussion when you write something like this, right?
First of all, by extension of your argument (to keep everything consistent and therefore relatively easy to use, no matter the experience of the user), we’d also need
GroupNode.ellipseNodes etc. Where do we draw the line?
Furthermore, regarding your statement about there being no option of having “too much API”: Take a look at Java or PHP. Both of them have (due to their “nature”, Java with its “Standard Library” and PHP, well, because it has ) tons of APIs. Don’t get me wrong here: I’ve worked (and am working) with both languages in my job and/or my studies and appreciate many of these things. The one target audience who least appreciates this, however, are especially newer users not having much experience with programming (and therefore navigating and understanding technical documentation), to whom the fact that there are basically 100 ways of doing something (e.g., in PHP, should you, in the days when PHP 5 was the latest, use
new mysqli, the PDO APIs or something different). The answer is: There was (and, aside from
mysql being deprecated now, still is) no correct way for the PHP example. This means that if someone asks what they should use, they won’t get a real answer, and eventually get frustrated. On the other hand, doing something like filtering a list is “easy enough” and should be doable by the user, even if they’re less experienced (especially then, learning this is incredibly valuable as it teaches dealing with tree-like structures etc.). After all, there’s even a section in the guides for that: https://adobexdplatform.com/plugin-docs/tutorials/how-to-work-with-scenenodelist/#4-create-the-handler-function-for-filterandcolor.
I have to agree with @cpryland here. Things like that would clutter up the APIs, having children in many “places” feels counter-intuitive and does, in my opinion, not make it easier to deal with (by, in my opinion, even obfuscating the APIs. A node having
children makes sense. Having the same child in
artboardChildren, and by extension of that for
reactangleNodes does not make the APIs clearer).
Last but not least, forgive me for getting a bit technical here, but this also obfuscates performance. “Getting” a member always feels like an operation running in O(1). Instead, it will still have to filter nodes and therefore run in O(n), which becomes “invisible” without reading the documentation for every getter. When you loop and filter the nodes manually, you “get” that it is a loop and performance will be O(n) for it (and it’s easy to see that running 7 nested loops of that is probably not such a good idea). However, by obfuscating this performance, creating plugins that are performing well (which, according to https://adobexdplatform.com/plugin-docs/devbestpractices/1-performance.html?h=performance, is basically a must) will get much harder, especially for people without a CS background
All in all, while I get where you’re coming with this request, I believe this would do more bad than good, obfuscating without any real benefit. I feel like it’s a great thing that the APIs as straight-forward as they are (especially for ease of use), and believe adding such things for a bit of comfort for people familiar with all these APIs (you’d have to know a lot of functions, if you wanted to use such functions if they were to be included in the APIs, there are a lot of things that could be easier for developers ) wouldn’t do the APIs any good, especially considering newer users with perhaps less of a technical background.