I see in the api docs no virtual functions, so I can't break anything anyway, can I?
I guess you don't understand how virtual functions work - probably would be wise to learn about it properly if you're using classes in this way!
The purpose of these classes is that you'd add them to other components to add graphics; I never expected or wanted anyone to inherit from the classes themselves. Why would you want to override a class that just draws a primitive shape when you could simply draw the rectangle in your own class with one line of code, or add a DrawableRectangle to your class? Remember the golden rule of inheritance is that you should never use it if there's any other sane way to achieve what you're trying to do. There's a lot of good C++ tutorials out there that will help to explain the principle of preferring composition over inheritance.
Ahh really? Well the documentation says "base class" so I figured that's what they were for. Before, I would just inherit from something like DrawablePath or DrawableShape then set the path to the shape I wanted. I thought it made it quite easy to do. It might be useful to add a note in the documentation. I had no idea.
Are there any examples of you using them? I'm curious now.
Edit: Ahh I see how you used it in the Demo after searching GitHub. Yeah I suppose that it is much better to use it that way. I guess I got confused about how you intended for it to be used. Thanks for clearing that up!
I guess you don't understand how virtual functions work - probably would be wise to learn about it properly if you're using classes in this way!
Well, I'm always happy to learn something new. But owning a degree in comouter science and programming C++ for more than 10 years now makes me confident, that I know, what I'm talking about.
I admit I did not follow the OPs example into detail, and I agree that there is no need to derrive from these Drawable classes (I had in mind DrawableButton, which shares only the name but not the inheritance. If I've seen this I would probably have skipped this topic completely). But the answer to why is often "because I can" ;-)
No seriously my only point was, if a class is not intended to be derrived from and if it's dangerous to do so, please take the time to write it into the docs. The time you spend in writing, a hundred users will save...
Remember the golden rule of inheritance is that you should never use it if there's any other sane way to achieve what you're trying to do.
That's actually athing that worries me often in the way how the juce architecture works. A lot of customization of components I can only achieve by inheriting and override functions. On several places I wished it to be more like QT, where you can use the widgets and customize the instances rather than creating new classes. But I accept this as personal preference and work along these lines.
There's a lot of good C++ tutorials out there that will help to explain the principle of preferring composition over inheritance.
This is a statement that would start a long debate which I don't want to do. Just want to add that some architects even prohibit composition because it can lead to undefined behaviour if you compose two objects where both implement the same method. Probably a good compiler will warn you, but this is a field I don't know too much of, and that's why I am always very careful with multiple inheritance.
And I'm not telling you anything new, so we can leave this out...
