Thanks, Kassen, for your reply.
You're welcome!
Yes, sorry, my mistake - I meant device.
I suspected so, yes.
It does and I probably wasn't clear. I'm curious to know if, when a shred terminates, there is a way for the application to be made aware of it. For example, there could be a onShredExit(Shred@ shred) callback function automatically called by ChucK just before the shred terminates whose content would be left at the discretion of the user so that for instance s/he could write some code to notify all the objects dependant on this shred. But I guess there would be potential scope issues...
Yeah. What we do have is "Events". Events can be made a static part of a public class and thus be system-wide. If you do that a shred that's exiting could broadcast this event first, using it's own Id as a parameter. Other shreds might then mourn the loss of their friend (or squable over who gets the poor shred's room). Events are very usefull, I think they could fill the functionality you are after.
What about functors or some sort of pointers to functions and member functions? Now, that would be really great!
I'm not sure what "functors" are but I'd like pointers to functions as well, especially if I could have a array of functions for situations where you are sure *somthing* needs to be executed but exactly what it is depends on some parameter. What you can do is make a whole bunch of classes, each containing just one function (called "do" or something similar) and asign those to a array. That would at least create this functionality, at the price of being very roundabout and likely needing lots of comments to avoid baffled looks and confusion. This would result in something like this; myfunctions[n].do(); Which should execute function number "n" as that would be the function in the class asigned to position "n". Yours, Kas.