This still leaves the possibility of opting-in. Let Component derive from ReferenceCountedObject, let its constructors opt-out and let us opt-in if we want autodeletion.
Not sure I can see that. PHP is insecure by design, Perl is a write only language, etc. Lua is a perfectly decent language for doing all kinds of things, as long as you treat the tool with respect. At the end of the day, it’s a scripting language, with loose typing, minimal datasets, and all that implies. I wouldn’t want to generate 30,000 lines of Lua, but then I’ve seen Perl scripts of less than five lines that make my eyes water.
The extensibility of Lua is what makes it popular IMHO. a 200Kb compile is a obviously a major factor for embedded systems, but the beauty, and peril of Lua is that you can make the language work more or less how you need. For my stuff I present a straight OO interface to my users, and largely shield them from functional programming idioms. I could just as easily have taken the exact opposite approach however.
This is a huge PITA. I ended up creating wrapper classes that manage components, and their lifetimes outside of both JUCE and Lua. Typically that meant sub-classing a component, creating a wrapper class, then creating a bindings layer to Lua.
For me, since many of the components I make available to script writers are custom, it’s kind of a moot point, as the overhead was actually trivial in comparison to creating the component classes, and filling out the bindings.
It’s not a trivial problem to solve, and not one that is easily generalizable. Despite that, I wouldn’t want to see JUCE bogged down with code to allow for binding support at the cost of performance/usability for everyone else. If I wanted to program in a Cish language with garbage collection, I have other options.
A more interesting questing would be whether JUCE could be extended to support dynamic messaging, but I’m not really sure how that’d work.