[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 :
[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