On Wed, 25 Nov 2009, Roman Haefeli wrote:
However, it doesn't, which makes you have to learn every single case separately. Smartness doesn't help here, only diligence. Unfortunately, when it comes to Pd data types, smartness doesn't apply. So we're left with documenting all_(the special cases)_about_data_types(.pd).
The only way to cover everything is to read all of the source code of pd. Every exception that is really an exception will have its own piece of code. Consistent cases that have their own piece of code just slow you down in reading that source code. This is why I took a lot of steps to separate difference and repetition in the pd source code, by using various means such as overloading, macros, meta-macros, abstracting out more functions, and formatting code so that it looks like a table. Eventually, stripping out all the redundantly repetitive mechanics that you can deduce from whatever else, you are left staring at the pure intent behind it all. I didn't reach that point and seldom it is reached by anyone, but the closer you get, the more transparent it becomes.
If there are things two say about some the of the (special or not) cases, wouldn't it be a good idea to simply add them? Generally i think, that having such a patch isn't a bad idea, since it helps one not to have to find all the cases by experience.
Black-box reverse-engineering is the best when you have no other option. Otherwise, do peek under the hood and the source code will tell you everything you want to know. It's probably shorter to learn enough C/C++ and then read pd or dd, than to figure out by yourself all imaginable ways to poke pd's components so that every detail of their behaviour comes out!
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801