[PD] PD OOP?

[brandon zeeb]

In my experience with emulating OOP in Pd I've had moderate success.  As a
Java developer by day, I find myself attempting to recreate familiar
patterns within Pd (ie: usually IoC and Flyweight in Pd).   Main problems
with recreating OOP in Pd are the following:

   1. Everything is global
   2. No control over abstraction (object) construction order and lifecycle
   3. No introspection (although not required, very helpful, and don't tell
   me it's in some external, I don't care!)
   4. No concept of "this"
   5. No interfaces or abstract abstractions (to control inlet patterns)
   6. Unfriendly and inconsistent type system (it is cumbersome in real use,
   although I get over this by using [list])
   7. and on and on

In most Pd patches, I see people using a few lookup tables again and again
(ie: mtof).  As this is a complete waste of memory, one can attempt the
Flyweight pattern.  However, doing so in Pd is a very dangerous game, as you
will have NO idea which abstraction first created the table and thus have no
control over retaining access to it.  In my library I've dropped this
approach in favor of something closer to IoC.

Basic IoC is very possible, and indeed very rewarding.  Very often I pass in
other abstractions as object creation arguments.  The most simple example of
this in my library is my [bypass~] abstraction used to dynamically enable
and disable a given abstraction.  I use this EVERYWHERE to save CPU cycles
in combination with another object to programmatically disable the
sub-abstraction when the user selects a given value (ie: when the filter
cutoff is at MAX with no resonance, disable the filter).

In use:

[bypass~ some_process~ 330 1 3 9]

Where [bypass~] expects it's 1st argument to be an abstraction and the next
10 to be arguments to that abstraction.  Every patch which uses [bypass]~
must have 1 signal inlet and 1 event inlet.  Unfortunately, this interface
can't be programmatically enforced. [bypass~] passes it's 1st two inlets to
the sub-abstraction, while the 3rd is used to control [bypass~]

I've attached [bypass~] and it's dependencies, have fun!

~Brandon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/68cdb747/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bypass~-help.pd
Type: application/octet-stream
Size: 446 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/68cdb747/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bypass~.pd
Type: application/octet-stream
Size: 1104 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/68cdb747/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mute~-help.pd
Type: application/octet-stream
Size: 620 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/68cdb747/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mute~.pd
Type: application/octet-stream
Size: 1695 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/68cdb747/attachment-0003.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defined-help.pd
Type: application/octet-stream
Size: 746 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/68cdb747/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: defined.pd
Type: application/octet-stream
Size: 499 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/68cdb747/attachment-0005.obj>