[PD] OOP practices in Pure Data

abel.jerome at free.fr abel.jerome at free.fr
Thu Dec 1 00:37:14 CET 2011

> So are you really commenting about OOP techniques, or are you commenting 
> about programming conventions of all kinds ?

In fact, it's a mix of practices. The purpose is to find words to describe my practice and find what is common to be a "good" patching style. Anyone making a library of abstractions is trying to make common rules. It's easier to understand, maintain, share, etc. A good example is this work : https://github.com/danomatika/rc-patches

> How do you justify that $0- variables are like the «private» keyword in OOP ?

It makes sense for me to use $0- variables inside an abstraction like private one.
Of course, I know that it is possible to send a message outside this scope.
However, it seems useful to separate variables.

> Why are the three parts of your MVC design patterns not matching the Model/View/Controller separation that gave the name to MVC ?

Because, like you see, it's not really a MVC design. It is more like an inspiration to design a patching architecture.
The model could be : PROCESSING
The view/controller : GUI
An extern controller : commands from outside ?

> Why would .h files and/or class interfaces, be considered as one of the three parts of MVC ?

I think it is closer to the class separation between interface (.h) and implementation (.cpp) than MVC.

> Why don't you distinguish between messages, selectors and methods, in your naming ?

Naming of variables ? like m_fVolume for a private variable with a float type ?
At this level, if I distinguish between variables and methods here, it seems not very useful. 
It is just setter methods. It could be :

[inlet commands]
[route setVolume setFrequency] : setter methods
[send $0-volumeIn] : variable is updated

> Why do you make a subpatch for communication and then use named send/receives inside
> of it to send to other subpatches ? What do you gain from this ?

It's a balance. Separate processing and communication is clearer for me than putting all together.

> Why do you join [initbang] and [loadbang] together as a single [r
> $0-loadbang] that receives _two_ bangs per object-setup ?

That's a mistake, indeed. I use to work with dynamic patching, it's a stupid reaction.

> What are the things that we are supposed to learn from that document ?

Is it useful to share thoughts with people ?
I learn about your paper "A Type Theory for the Documentation of Pure Data" and fix a mistake.


More information about the Pd-list mailing list