Reason for ValueTreeListener class member functions to be pure virtual?

Working a lot with ValueTrees recently I regularly find myself implementing some classes that inherit ValueTreeListener which just needs to listen to only one of the member functions (mostly propertyChanged). However as there are 5 pure virtual member functions I often implement four empty member functions.

I know I could work around this just like David Rowland does it in his famous ADC talk regarding ValueTrees and implement some ValueTreePropertyChangeListener class that just overrides all other member functions with an empty function body, however I wonder if there would be any downside in just not declaring those methods to be pure virtual and let the user decide which functions he or she actually needs to override?

I would be happy for either a quick explanation of the reasons behind this design decision or if there is no problem with declaring them just virtual with an empty function body to turn this into a feature request!


I guess the argument for this is that making the interface pure virtual forces people to think about what methods they need to implement and breaks code when new ones are added, but since the valueTreeRedirected() method was added and isn’t pure virtual I think it’s fine to remove the others. I certainly find myself writing a lot of code that only implements valueTreePropertyChanged() and uses stub functions for the rest or uses some sort of wrapper so it’d be nice to remove the boilerplate.


I used to agree with them all being pure virtual but the more I use them the more I’ve changed my mind on this.

For me they kind of come it sets, you’re usually either interested in the property changing or add/remove/order change or redirection.
There are obviously exceptions to this but that’s the common patterns in a lot of our code.

I would add a caveat to this that I’ve been using ValueTrees for a long time though and maybe for people noew to them having them pure virtual does force them to understand the operations a bit better.