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 <[email protected]> wrote: > What exactly would "this" (#4) look like in Pd? > > -Jonathan > > --- On *Wed, 12/15/10, brandon zeeb <[email protected]>* wrote: > > > From: brandon zeeb <[email protected]> > > Subject: Re: [PD] PD OOP? > To: "PD List" <[email protected]> > 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----- > > _______________________________________________ > [email protected] <http://mc/[email protected]> mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > > > -- Brandon Zeeb
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
