[PD-dev] Refactoring Pure Data

[Mathieu Bouchard]

On Mon, 11 Sep 2006, Vincent Lordier wrote:

>> So, supposing you want to work with Miller
> Why no ?

Because you want to refactor Pd and because, I suppose that you've read 
pd-list and/or pd-dev for some time.

> To me, I shouldn't have to "work with Miller" or "work with Mathieu" or 
> anything like this,

So you are going to work alone? Or you're going to reunite the family?

> simply because we are wasting way too much energy doing theses diffs / 
> merge stuff. Having different branches is fine and even desirable (!),

If there's not going to be merging then what do you want the branches to 
do? split further apart?

> as long as it leads to more generic modules that can be tested and 
> refined in more diverse cases.

do you do unit-testing?

> Let's face it : Pd is wonderful and mostly well written,

It's well written in the sense that it doesn't have so many bugs.

> but its code is a little hairy (no offense intended).

I'd say it louder and bolder than that.

> It deserves a clear roadmap,

Several people have their own roadmaps. Does it need one big shared one? 
Just how shared would that one be?

> I think this work on architecture will be mandatory as we add new 
> features (like video~)

Do you think that adding a sixth video subsystem to pd is going to solve 
anything?

> The solution isn't to make forks on forks IMO : the key is to reduce the 
> amount of code to be merged. Making Pd more modular allows to work on 
> what you want,

You don't understand what I mean: there's a catch-22 (a deadlock) - 
modularizing may reduce the amount of merging in the long term, but in the 
short term, it's increasing it, and that's what will prevent 
modularization from happening in the current branches, despite its 
benefits.

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

Actually, I also have the goal of refactoring, of course, but I can't 
guarantee invariance of behaviour in any way...

> - Self explanatory naming (how many single letters variables and / or 
> funny functions names do we have ?)

most names don't have to be long, especially when local and also 
especially when often used.

> - Short functions (20 lines)
> - Reasonable Cyclomatic number

I agree on both of those.

> - Short files (100 to 200 lines)

I don't believe this buys us any advantage, and actually has several 
disadvantages. This is why I put all of the DesireData server-side code in 
one file, and most of the client-side code in one file too.

> - A little indenting

I haven't seen any spots in PureData where the indentation was not done, 
or not done correctly, according to its own rules. I might not like the 
way it's indented, but I can say it's indented the same everywhere I 
looked. (DesireData is not nearly as uniform in its indentation).

> - Getting rid of stuff.h which is a nonsense to me and having .h in modules
> when required.

I agree about splitting s_stuff.h or otherwise cleanly indicating what its 
sections are; however I don't know what you mean by having .h "in" 
modules. Is a "module" some kind of directory?

> Maybe Pd's internals architecture could be a nice topic for a little IRC 
> meeting ?

I stopped caring about trying to organise PureData developers meetings 
some time ago. I think we've had seven of them. It didn't catch on.
I decided to call DesireData meetings instead, but the 2nd meeting is 
loooong overdue.

> Who's in ?

I could be in. Is this going to happen on #dataflow ?

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