On Thu, 19 Jan 2006, geiger wrote:
there are some things which make this a bit more complicated in some cases. e.g. as Thomas noted if you want to reuse code in several "internals/externals". This might be important in the SIMD case, but maybe you can factor out standard operations into macros and reuse those. For PDa I had to come up with a workaround for sine tables that are used by some oscillators.
I think that the Pd source doesn't use nearly enough macros or other code-reducing tricks.
The reduction of code isn't so much about making things use less RAM: the RAM excuse is quickly evaporating as even the tiniest computers come with plenty of RAM and even the faster kinds of RAM come in ever more copious amounts (big caches).
The reduction of code is programmer-oriented. I'm not talking about length of identifiers here (this is a separate issue). Every line of code should do something interesting by itself. Code should read like a good story and not like a car. Ever tried to read a car? It's boring. The same damn piston copy-pasted 12 times.
The reduction of code is also documentation-oriented. Once the programmer has been contaminated with the wisdom required to make small code or understand small code, then why wouldn't the programmer explain it to his students in higher-level terms instead of chanting 12 times the same piston as if it were a marathon of Hail-Marys ?
This is why Pd needs a taxonomy of object classes. If I don't get that taxonomy in Pd itself nor in its help files, at least I'll have it in its unit tests.
Once and only once. Once and only once. Once and only once. Three strikes and you refactor. for x in [1,2,3] say: Once and only once
http://c2.com/cgi/wiki/?ThreeStrikesAndYouRefactor
BTW I'm not talking about only inheritance of implementations. The most important thing to me is inheritance of expectations, so that if I name 100 classes that obey the rule "Operator2", then you have just learned something common about 100 classes.
Operator2 means right-inlet is cold, left-inlet is hot, there is a "set" method for using left-inlet as cold, there is a "bang" for explicitly activating the main computation. The main computation only produces one message. That's what "Operator2" means in my taxonomy, and it's that much that hasn't to be stated explicitly in each help patch.
Help patches can be abstractions to be used to by other help patches. Just put a [operator2-help] object in your help patch to indicate that the currently documented class obeys the standard operator2 rules.
Who's against it?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada