[PD] OOP practices in Pure Data

[Mathieu Bouchard]

Le 2011-12-01 à 00:37:00, abel.jerome at 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