[PD] PD OOP?

[Jonathan Wilkes]

What exactly would "this" (#4) look like in Pd?

-Jonathan

--- On Wed, 12/15/10, brandon zeeb <zeeb.brandon at gmail.com> wrote:

From: brandon zeeb <zeeb.brandon at gmail.com>
Subject: Re: [PD] PD OOP?
To: "PD List" <pd-list at iem.at>
Date: Wednesday, December 15, 2010, 1:51 PM

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:

Everything is globalNo control over abstraction (object) construction order and lifecycleNo introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!)
No concept of "this"No interfaces or abstract abstractions (to control inlet patterns)Unfriendly and inconsistent type system (it is cumbersome in real use, although I get over this by using [list])
and on and onIn 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


-----Inline Attachment Follows-----

_______________________________________________
Pd-list at iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list



      
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20101215/8519d8fb/attachment.htm>