[PD-dev] macros and such (was: pd-lib, SIMD)

[Mathieu Bouchard]

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