[PD-dev] Refactoring Pure Data

[Mathieu Bouchard]

On Mon, 11 Sep 2006, Vincent Lordier wrote:

> I want to work on pd's code readability and structure, only refactoring, 
> not adding new features. (http://en.wikipedia.org/wiki/Refactoring)

Making diffs and applying diffs doesn't go too well with refactoring. 
This leads to large diffs that clash easily. The only way to eliminate 
this problem with refactoring would be to use a super-sophisticated 
diff program that understands the language it works with. (This 
won't happen with the C language anytime soon...)

So, supposing you want to work with Miller, you should get agreement with 
him about doing this, because the diffs you would submit will expire 
rather quickly by conflicting with other diffs. This said, I don't think 
Miller wants any help with that, but I'll let him tell you.

> 'We've got to undo the MIDI revolution!  said Miller'

This sentence is misleading. Pd doesn't undo the MIDI revolution, it goes 
beyond it. There's no going backwards here.

You could work on devel_0_39, but I doubt you can make any big changes. I 
once tried to remove unused variables from the code, and my change got 
reverted. Any change that doesn't bring a new feature is likely to be 
reverted, IMHO. This is both due to the diffing process used for 
submitting diffs to Miller and the diffing process used for merging new 
Miller releases into devel (supposing that there will ever be a 
devel_0_40... I don't know yet). Those are factors that encourage to keep 
devel_0_39 as close to Miller's as possible.

I've done heavy refactoring, but that was only the GUI section, and it 
isn't strictly refactoring, as there has been a bunch of established 
features that haven't been working for many months. Even then, the way I 
did it was to copy all g_*.c files into one big file, desire.c, and then 
in the buildfile, conditionally compile either g_*.c or desire.c. And then 
I work on the big file only, except for some changes that really had to be 
done in other files, but those changes are kept to the strict minimum.

While this same concept could be used in other parts of devel_0_39, soon 
we wouldn't have a reason to not have a separate branch for that kind of 
work...

I don't plan to do more of this forking before I actually switch to using 
my own GUI... and even after that I'm not sure how long I'll take. Until 
then, I'll only fork the files that I really need to fork, if I find any.

> => Well, as far as I know, removing MIDI from PD's hairy code isn't as easy
> as "./configure --nomidi' make install ... yet !

Why do you need to remove MIDI? Is it for code structure reasons or do you 
also have needs for that? (running Pd on very small computers...)

> Again, my goal is not to alter pd in its behavior (yet),

my goal is.

> just to improve readability and separation of modules.

Pd's style guide says that the one-or-two-letter prefixes on all the 
struct member names are there for "readability" purposes. That's not my 
kind of readability at all. What's your kind of readability? What does it 
mean to you?

> BUT my main problem right now is : on which version / branch should I 
> work on ?

I wish you good luck in figuring that out.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju
| Freelance Digital Arts Engineer, Montréal QC Canada