On Dec 22, 2007, at 6:07 PM, Sam Pluta wrote: Looking at this thread I am thinking the best way to do this is to make a class that contains your data. Also, there might be processes that go along with the data that a class would complement nicely. Nothing like Classy code to neaten things up a bit. Well, let's make the choices really confusing, then :) I'm not convinced that classes are the best choice for everything. Actually, by this point I'm very strongly convinced that classes are the wrong choice for some uses. Specifically, if it's something where your needs are likely to change frequently (which is often the case in composition... how often do you know from the very beginning exactly what you need? Umm... never), classes can get to be a real pain because you have to recompile the library all the time. Nonetheless, grouping related objects and activities into a larger object does clean things up a lot. I've been using prototype-based programming a lot (see my ddwProto quark) when I need something that acts pretty much like a normal SuperCollider object whose definition will need to change at runtime. I find it a good, middle way position: cleaner than keeping everything in a single namespace, but more convenient that hard coded classes. hjh : H. James Harkins : jamshark70@xxxxxxxxxxxxxxxxx : http://www.dewdrop-world.net .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman |