Questions on class-checking and Objective C-like interfaces
Chuck Devs, I brought up something like this a while back on the users list, regarding general modulation functions, but I'm wondering if it wouldn't be that tough to implement in a seriously reckless build of ChucK. In Objective C, you can have something take "(id)" as an argument, which basically means anything. The compiler leaves it up to the programmer to get things right, which allows great flexibility during run-time operation. I was thinking that ChucK could get this by basically just ALLOWING (not requiring) the option to not check class methods. This would allow code like: // begin fun void modFreq ( UGen a, UGen b ) { while (true) { if (BoolBus[0]) { a.last() + 440 => b.freq; 64::samp => now; } } } SinOsc mod => blackhole; SinOsc car => dac; spork ~ modFreq( a, b ); day => now; // end This code is totally possible in current ChucK versions (replacing UGen b with SinOsc b, of course) but what happens if you want to modulate something else, in another class but still with a freq method? You have to create all new functions, all the time. This isn't really a huge deal if you have a giant code library, but it's not like it's fun or anything, and you end up with tons of obscure functions, maybe public class static functions like "SinMods.freq( a, b )" in these endless trees (well, not endless--there aren't quite that many UGens). It seems like this could be possible by disabling the compiler warnings. Naturally, this could lead to huge disasters, which is why I feel like it should be made optional (and possibly hard to initialize, just to protect people from themselves). Is this possible? I imagine that it wouldn't be that hard to switch--build another version of ChucK with the specific checking features turned off, and call it chucknorton or some equally dangerous-sounding name. Then you just type chucknorton + crazymods.ck and you've got some universal modulation functions. Lots of list posts lately, so sorry if these are just totally off-topic or stressful for some of the (real) devs. Longer recessions make for better open source software, though. Andrew
participants (1)
-
Andrew C. Smith