[PD] PD OOP?

[brandon zeeb]

Many options have been proposed over the years, my favorite thus far is
[thiscanvas]
http://lists.puredata.info/pipermail/pd-dev/2004-12/003430.html


On Wed, Dec 15, 2010 at 8:34 AM, Jonathan Wilkes <jancsika at yahoo.com> wrote:

> 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:
>
>    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
>
> -----Inline Attachment Follows-----
>
> _______________________________________________
> Pd-list at iem.at <http://mc/compose?to=Pd-list@iem.at> mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
>
>
>


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