On Sun, 9 Sep 2007, marius schebella wrote:
I think that is true not only for code, but also for patches.
I don't make a distinction between patches and "real code".
atm automatic testing is still very complicated to do (at least I would not know how to write it). but testing could also be "manual".
No, it should be pretty clear that it can't be manual. At least it should be semi-automatic: the patch guides the person and shows results that are easy to verify for the person but hard to do for the computer.
I really like the idea to start patching with a help patch where the object inlets and outlets and functions/features are defined before starting with the external itself. maybe that also would make patches more shareable... marius.
This works if you have something specific in mind. If you are making exploratory programming, this can't work. However, in the process of making exploratory programming you may encounter a pattern that you want to turn into an abstraction, just like when doing any programming. At this point it becomes less exploratory and more defined... well, maybe you are not sure about how the abstraction would be used yet, but that's normal; at least you know where you're heading. What I mean by exploratory programming, is to noodle around with your program until you find something you want.
One annoying thing with Pd, is that before you make the help patch, you have to make at least a skeleton of the class you want to make, so that you have inlets and outlets to connect in your help-patch or test-patch. It goes a bit against the spirit of "test-first", but it's not a big loss.
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada