Inheriting from component and audioProcessor

General JUCE discussion
1

Something that’s been bugging me for a bit …

Generally one keeps UI functions far separate from audioProcessor Callback related functions (naturally, since we don’t want the processor accessing UI methods which are way too slow to try and do every time a callback comes up). This is so obviously the proper paradigm that we have functions like AudioProcessor::createEditor() to show that the processor should CREATE a UI component, not BE a UI component.

So … I thought of it as a fun experiment to see what would happen when I made a component inherit from both the component class and the audioProcessor class, and cause the above function to simply return “this”.

Surprise - no real problems. I keep thinking I am breaking the rules and something bad must happen, but as long as I keep the UI methods well separate from the processor methods, it seems like there is no real issue here.

Now, I’m not planning on doing things this way most of the time, but I was wondering if there are any big drawbacks that I am not seeing here ? … or is it the case that these two classes are kept at arms length more because of convention than necessity?

2

Wow. That’s horrific. I can think of several ways that would cause real, serious bugs, not to mention the fact that in terms of c++ style, it stinks!

Anyone who doesn’t instinctively recoil at the very thought of it probably needs to learn about inheritance vs composition and why composition is generally better. Try this:
http://www.artima.com/cppsource/codestandards3.html

3

Ha! Like I said, I know it’s not the right operating procedure … but a fun experiment none the less. I was a little surprised when the sky didn’t fall.

Great article too - I couldn’t have come up with a list of reasons that thorough, it gives me some new things to think about.