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