Maybe the name
getRoot() will be better? whateve…
Maybe the name
Yep, good request, will add that.
But it’s worth noting that despite doing many huge and very complex apps using ValueTrees, I’ve never needed such a seemingly obvious method before. That may just be by chance. Or it may be a hint that perhaps code that relies on such a method isn’t particularly well designed? I imagine there are some solid use-cases for needing it, but beware!
Yes, in most cases, ValueTree::Listener’s methods nearly can do everything I need. but things always have exceptions…
There are exceptions, but my point is that I’d strongly suggest that you’re very suspicious of why you think you need to call this function.
It’s hard to explain, but let me try:
In general I’ve found that we tend to write classes that encapsulate a particular type of ValueTree, and those classes are given a reference to a tree which they wrap. Usually, the tree you give them will be a sub-tree of a bigger structure. (e.g. in tracktion, the entire project is a tree, and there are classes to wrap sub-trees like tracks, clips, etc).
If those classes do anything that involves iterating up to the parents of the tree you gave them, then you’re baking-in implicit knowledge about structures that probably aren’t their responsibility. Sometimes that’s sensible, but usually it’s a code-smell.
Thinking about it, I reckon the reason I’ve never needed a method like this is that it’s just dangerous to assume that the root node is what you expect it to be. Whenever I’ve had to write code which looks up the parent hierarchy to find a particular object, it’s invariably a better to write a function which searches for a tree with a specific type or other characteristic. Just getting the root node and assuming it’s the thing you want is the kind of tacit assumption that causes nasty future bugs.
What I wouldn’t give for a look at tracktion’s source to see the wizardry that has gone on in there…brought a copy so I could have a decent DAW for Ubuntu and I’m in love with it.
I totally agree with your opinions, Jules.
Use or not use, the decision should rests with the library’s users (e.g. me). Of course, the greater the power, the greater the responsibility. However, Has or not has, it’s a duty (integrality?) of the library…
I don’t think the nocuity of
ValueTree::getRoot() will more than
File::deleteRecursively(), TreeView::getRootItem() and so on…
My case is very simple and I’m not willing to use the ValueTree::listener in that big-class which owned the root-tree… I’m sure it’s not a good design though…
// auto save(backup) the project after some special changes or seconds.. ValueTree rootTree = docTree.getParent(); // docTree is a member of this class while (rootTree.getParent().isValid()) rootTree = rootTree.getParent(); if (! MyUtilities::valueTreeWriteToFile (rootTree, projectFile, false)) SHOW_MESSAGE (TRANS ("Something wrong during saving this project."));
Hmm, it looks to me like very bad design for some code which only has a reference to a sub-tree to be responsible for saving a file containing the whole tree. Where’s the code that has the reference to the top of the tree? Why isn’t that code doing the saving?? It may work OK for you, but if someone on my team wrote anything like that, they’d get a hard time in the code review!
When someone speaks to the integrality of your library, you’re always talking about his design within making a deliberate misinterpretation out of context and show your pride seize the opportune moment stand high above the masses…
Never mind… one line code could solve my problem and more readable. I’m surely knowing what I’m doing, just one line…that is all.
I read this as Jules trying to encourage good design by carefully selecting the API to provide.
I’m guessing that getRoot() will just call getParent() until it returns an invalid ValueTree? That’s only three lines of code.
Maybe you didn’t notice, but I actually did add ValueTree::getRoot() to the library yesterday.
Like I said originally, it’s a valid request, and a good method for the class to have, which is why I added it.
My other comments were really just intended as helpful advice, because we so often get people requesting sensible things for the wrong reason, and this looks to me like one of those cases.
Thanks for your reply.
I think “design” should be encouraged by user rather than author of a library / app.
I’m sure there’re lot of methods less than 3 lines in JUCE lib. Think about this: if it hasn’t those methods…
so quickly:) Haven’t pulled it yet…
I always feel great indebted for your words, encourage and the great library. Nearly all my C++ knowledge / skills come from JUCE and this forum (if I have a little )
I’m not a professional programmer, just like to write some code, make some little apps for myself and few of my friends. I enjoy it, don’t want any hard time:)