You're right, we need a lot more... This little trick isn't meant as a replacement for anything but what it *could* do is allow one to quickly store something in a way that will survive the end of the VM and being able to get it back in there next time ChucK is started. Previously I couldn't think of a way to do this without also involving other things and terribly ugly and inefficient forms of abuse.
Hello self-modifying code... ;-)
Without proper string manipulation this is limited to the only sort of file ChucK can deal with properly being ChucK code, yes.... Still no parsing of strings by groups of letters to feed to the speech synth for example(I'd like that...). But, this *would* allow for permanent storage of -say- patterns of ChucKian sequencers.
I think a really nice use of serializable objects would be to take care of a complaint in that previous thread about live coding... you've written a routine to randomly generate a nice melody (based on a severely complicated algorithm of course), but when you decide to modify something, oops you've lost it because you have to restart. So a nice feature might be to allow saving an object to a file. Next time around, the code could attempt to load the object from disk. If successful, go nuts with it, but on failure, generate a random melody and save the object to disk... (Of course this brings up all sorts of real-time issues. I guess saving & loading would have to be done asynchronously somehow, but I think a bit of buffering could take care of that.) Steve