Le 2011-12-01 à 00:37:00, [email protected] 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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
