Hi all,
All along years of practice, I've developped with Pd as well as object oriented languages. Some methods and designs from OOP (object oriented programming) structure my patches, because I think they are very useful to clear thoughts and share patches. It is sometimes difficult to understand patches from other people, and more difficult when it is a complete project. Therefore I think it's quite "good" to link Pd programming with OOP.
In the same idea, I like those resources : http://puredata.info/docs/tutorials/TipsAndTricks http://puredata.info/Members/bbogart/pddp http://puredata.info/docs/style-guide http://www.earcatching.com/pdconv/pdconv.pdf
Sharing practices is also very useful to help eachother and beginners people structure their code (and their thoughts).
Jerome http://jeromeabel.net
What a great resource. Thanks Jerome. Cool to see some of my old patches in there as examples (of what not to do) :)
On Wed, 30 Nov 2011 13:31:09 +0100 (CET) abel.jerome@free.fr wrote:
Hi all,
All along years of practice, I've developped with Pd as well as object oriented languages. Some methods and designs from OOP (object oriented programming) structure my patches, because I think they are very useful to clear thoughts and share patches. It is sometimes difficult to understand patches from other people, and more difficult when it is a complete project. Therefore I think it's quite "good" to link Pd programming with OOP.
In the same idea, I like those resources : http://puredata.info/docs/tutorials/TipsAndTricks http://puredata.info/Members/bbogart/pddp http://puredata.info/docs/style-guide http://www.earcatching.com/pdconv/pdconv.pdf
Sharing practices is also very useful to help eachother and beginners people structure their code (and their thoughts).
Jerome http://jeromeabel.net
Some OOP stuff related to Pd is addressed here: http://artengine.ca/~catalogue-pd/43-Bouchard.pdf
For sharing the same $0: I think my canvas "get" method addresses that. There are probably several ways one
could do it. I already have a [send2canvas n] abstraction where n is a float that sets where in the canvas hierarchy
to send to-- so maybe I could also add the possibility to specify a symbolic arg, like [send2canvas foo] so that
[send2canvas] climbs the canvas hierarchy until the "filename" attribute for that canvas is foo.pd. Sending
"get dollarzero" to [send2canvas foo] would output the $0 of the container "foo" abstraction, if it exists.
Then you'd have:
[send2canvas 0] -> local to "this" canvas
[send2canvas foo] -> use this to get a common $0 for some arbitrary level of nested abstractions
[send pd-foo.pd] -> send to all instances of "foo" abstraction + any open as toplevel patches
I imagine [send2canvas foo] as I've just outlined could easily get confused with [send pd-foo.pd], so maybe there's
a better way to make the difference more explicit.
-Jonathan
From: "abel.jerome@free.fr" abel.jerome@free.fr To: pd-list@iem.at Sent: Wednesday, November 30, 2011 7:31 AM Subject: [PD] OOP practices in Pure Data
Hi all,
All along years of practice, I've developped with Pd as well as object oriented languages. Some methods and designs from OOP (object oriented programming) structure my patches, because I think they are very useful to clear thoughts and share patches. It is sometimes difficult to understand patches from other people, and more difficult when it is a complete project. Therefore I think it's quite "good" to link Pd programming with OOP.
In the same idea, I like those resources : http://puredata.info/docs/tutorials/TipsAndTricks http://puredata.info/Members/bbogart/pddp http://puredata.info/docs/style-guide http://www.earcatching.com/pdconv/pdconv.pdf
Sharing practices is also very useful to help eachother and beginners people structure their code (and their thoughts).
Jerome http://jeromeabel.net _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
Le 2011-11-30 à 13:31:00, abel.jerome@free.fr a écrit :
All along years of practice, I've developped with Pd as well as object oriented languages. Some methods and designs from OOP (object oriented programming) structure my patches, because I think they are very useful to clear thoughts and share patches.
a few questions :
So are you really commenting about OOP techniques, or are you commenting about programming conventions of all kinds ?
How do you justify that $0- variables are like the «private» keyword in OOP ? Can we really say that there's anything like the «private» keyword in Pd ? Isn't $0- more like object-level scoping rather than access specifiers of the public/protected/private kind ?
Why are the three parts of your MVC design patterns not matching the Model/View/Controller separation that gave the name to MVC ? Why would .h files and/or class interfaces, be considered as one of the three parts of MVC ?
Why don't you distinguish between messages, selectors and methods, in your naming ?
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 ?
Why do you join [initbang] and [loadbang] together as a single [r $0-loadbang] that receives _two_ bangs per object-setup ?
Why does [symbolIsEmpty] notifies only when the symbol is NOT empty ? And then, wouldn't it be better to output a 0 or 1 float instead, just like [==] would do ?
In pd-oop-good-practices.zip, where is the line between what you are trying to show about OOP, and the supporting elements that aren't supposed to be part of your discourse ? What are the things that we are supposed to learn from that document ? What makes those practices good, and why ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
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.
-- Jérôme http://jeromeabel.net
Le 2011-12-01 à 00:37:00, abel.jerome@free.fr a écrit :
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.
Ah ok, therefore it shouldn't be named « OOP practices in Pure Data ».
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.
I mean that it doesn't look like how the «private» keyword works : instead it looks like the «this» keyword and all its implicit equivalents (any place where «this->» is implied when you don't write it).
Because, like you see, it's not really a MVC design. It is more like an inspiration to design a patching architecture.
Then why not refrain from calling it MVC ?
Various people have created various variants of MVC by using other names than «MVC».
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.
C++ courses might instruct you that .h is the place where all interfaces go, and that .cpp is the place where all implementations go, but it's not an actual requirement of C++, and many major libraries don't use such a rule.
STL is famous for putting much of the implementation in .h files.
Many projects have private classes that are put entirely in .cpp files because they're never needed by any other .cpp files than the one they're in.
Why don't you distinguish between messages, selectors and methods, in your naming ?
Naming of variables ?
No, naming of concepts !
A message is the thing you send, a selector is the part of the message that is used for choosing a method, a method is the part of the code that corresponds to a selector. In abstractions, typically, a method is a portion of a patch that appear after a [route] (or [route]-like]) object routes messages from an [inlet].
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.
I also think that it's not useful, but it's really not what I wanted to talk about.
[route setVolume setFrequency] : setter methods
Pd's setters never have any prefix. That's everybody's naming conventions so far.
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.
Given that every object in a patch communicates with every object it's connected to, how do you distinguish between the communications that you would separate, and those that you wouldn't separate ?
What are the things that we are supposed to learn from that document ?
Is it useful to share thoughts with people ?
Yes, but they have to know what are the portions of the patches that actually convey your point(s), versus the backend portions that aren't actually what you wanted to talk about. Those things are not identified and so, I'm not sure what am I supposed to look at and comment on, for example.
I learn about your paper "A Type Theory for the Documentation of Pure Data" and fix a mistake.
What mistake ?
| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC
-
abel.jerome＠free.fr -
Andy Farnell -
Jonathan Wilkes -
Mathieu Bouchard