Workaround for 'marked as final' for existing projects

So I’ve read up on why classes are marked final now, and I totally get it.

But should one want to just build an existing project from GitHub that’s littered with extensions of Juce classes, is there a way to tell the compiler to just let it slide just this once?

I can see Dfinal= mentioned, but googling that compiler flag doesn’t give me any info.

This makes the preprocessor remove all occurrences of final. That’s very hacky.

If you would share your use case, which class you want to enhance and with what functionality people could maybe suggest ways to achieve that without inheriting final marked classes.

It’s likely that those classes were marked final for a reason. Inheriting from them might be error-prone, so it’s probably not a good idea. Can you use composition, i.e. write a new class to wrap the existing class, rather than inheritance?

Yea like a said, totally get it. Final is there to stop us inheriting from classes that shouldn’t be inherited from. If it were my own code, I’d slap my self on the wrist and learn from my mistakes and go rewrite everything.

Use case is building an existing project for personal use who’s code base is littered with such naughty inheritances, but for all intents and purposes, worked just fine before final came along.

I seem to run into this problem more than I’d like though.

The general recommendation I can see on this forum is that inheritance=bad, composition=good. If you have old code using inheritance of juice classes and function overrides, better go rewrite everything.

Can anyone link me to some ‘well written’ Juce code (preferably an audio plugin) that successfully employs composition rather than inheritance?

I’m assuming the basic idea is to create new classes that reference the original Juce classes via public member objects rather than overriding in the class definition?

It’s hard to be helpful without knowing what classes are giving you this issue.
If you could be more specific about your current design, it would be much easier to think about a way to refactor it to solve the ‘final’ issue.

I’ve done a few basic things myself following various tutorials and looking at the examples here, but it’s always been just implementing the Juce classes as they are. I’ve never got as far as trying to extend classes with inheritance or otherwise.

More often I just stumble across audio plugins that have code bases on GitHub that…

-Have become broken and need updating to run properly, in current MacOS versions.
-Are cool as is, but would be way cooler if I could make a few tweaks here and there.
-Have an annoying bug that I could have a crack at fixing.

But to do that, I need to compile the code with a current target OS…
To do that, it usually requires updating the Juce modules…
The of course nothing will compile because everything was written using inheritance for everything possible (and ScopedPointer etc).

I’m enthusiastic enough to learn how to refactor code to use composition instead.

I’d just love to see a working example that adheres to the Juce coding practices that I can learn from.

I dont really want to publicly name & shame any particular project, but it’s always the same.

They are littered with new custom classes derived from Juce:: base classes, overriding functions where need be.

I understand the basic concept of composition from looking at c++ examples on Stackoverflow, but it gets a little more complicated when taking into account return types and how the new classes are used in the rest of the code.

Seeing how this usually plays out in a Juce project using heavy use of composition rather than inheritance would be a great way to learn, but I can’t seem to find any.

Does anyone know of one?

If they’re overriding functions then the base class wasn’t marked ‘final’.

Did you run into situations where you’ve found many projects inheriting from juce::String, juce::ValueTree, etc?

That’s the problem. Juce base classes weren’t always marked final in earlier versions, and before the world shifted to the inheritance=bad, composition=good paradigm, inheritance was the go-to.

Most of my coding experience is in Objective-C. Subclassing the NS* base classes was the recommended way to go. I never really ran into this composition thing, so I can understand why a lot of older Juce code was written this way. I can see the argument for composition and willing and able to learn. Just show me some examples (Juce) and I can be off on my merry way!

Can you provide at least one example of a class in those projects that inherits from a class that is now “final” in Juce?

I recall some people thought they could inherit from AudioBuffer in order to add a sample rate field into that and their code got messed up once AudioBuffer was marked final. (The correct approach would have to been to do a new class that has AudioBuffer as its member, as well as a member for the sample rate value.)

I think that if there are some public GitHub repositiories which you find interesting but which have not been updated in a while, there is no harm in naming them. I’m sure people here would be glad to take a look. Perhaps it doesn’t take much work to get them to compile again and then we all win :slight_smile: And it would help to better understand what you are referring to.