[PD] PD OOP?

[Mathieu Bouchard]

On Wed, 15 Dec 2010, brandon zeeb wrote:

>  2. No control over abstraction (object) construction order and 
> lifecycle

What's that ?

>  3. No introspection (although not required, very helpful, and don't tell me it's in some external, I don't care!)

Why do you don't care about externals that might do the job ???

IMHO, directing your criticism at pd-vanilla alone is extremely 
unproductive. You have to accept the fact that doing real work in Pd may 
require a lot of externals. It's sad, but it's like that. I wouldn't use 
Pd if it didn't have externals.

>  5. No interfaces or abstract abstractions (to control inlet patterns)

Strictly speaking, interfaces, or completely abstract classes, need only 
be made explicit in languages that have strict method-lookup. In languages 
like Python/Ruby/Perl/Tcl/ObjC/etc., all the lookup is at run time, and 
likewise for PureData. In those languages, there is usually no built-in 
way to declare interfaces, because the method-lookup wouldn't use those 
declarations anyway.

Strict method-lookup normally means that "anything-methods" don't exist, 
and that means that complicated workarounds have to be provided instead of 
solutions that depend on "anything-methods" and loose method-lookup.

I would like to know what you mean by "inlet patterns" here.

>  6. Unfriendly and inconsistent type system (it is cumbersome in real 
> use, although I get over this by using [list])

I once proposed alternate versions of [unpack], [select], etc., that had 
no type restrictions. There was a discussion on it. See :

   http://www.mail-archive.com/pd-list@iem.at/msg08636.html
   http://www.mail-archive.com/pd-list@iem.at/msg08644.html
   but also the rest of the thread...

> 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,

[mtof] does not use a lookup-table :

   t_float mtof(t_float f) {
     if (f <= -1500) return 0;
     if (f > 1499) return mtof(1499);
     return 8.17579891564 * exp(.0577622650 * f);
   }
   void mtof_float(t_object *x, t_float f) {
     outlet_float(x->ob_outlet, mtof(f));
   }

> one can attempt the Flyweight pattern.

Please first give an example of a useful use of the FlyweightPattern.

> [bypass~ some_process~ 330 1 3 9]

Is this just ONE kind of InversionOfControl (IoC) ? I'd guess that there 
are several quite different manners of doing that in Pd, no ? But I have 
trouble reading definitions and tutorials of IoC. I probably have used a 
bunch of different IoC techniques in Pd and other languages already.

I mean that even simple patches without any abstractions would use 
implicitly IoC in some manner.

> Where [bypass~] expects it's 1st argument to be an abstraction and the 
> next 10 to be arguments to that abstraction.

If you used externals, you could make the number of arguments to be 
variable and unlimited. You could also make it lookup the abstraction in 
the parent's folder, so that I can put some_process~.pd in the same folder 
as the main patch, for example.

> Every patch which uses [bypass]~ must have 1 signal inlet and 1 event 
> inlet.  Unfortunately, this interface can't be programmatically 
> enforced.

It's enforced at run time. There's also nothing wrong to having more than 
2 inlets in this case, as long as you wouldn't be using the extra inlets 
in that case anyway (or can do without them).

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC