[PD] libraries in Pd-extended 0.43

Mathieu Bouchard matju at artengine.ca
Tue Dec 14 16:36:28 CET 2010


On Mon, 13 Dec 2010, Jonathan Wilkes wrote:

> You're right. I'm an object-o-phile.  But do you find "Related 
> Objects" troubling-- should it be "Related Classes"?

well... yes

> In a lot of situations you need both.  For something like canvas_class 
> it doesn't make much sense to put all the details of "what the class 
> does" in one giant help file

Giant help files aren't much of a problem, but it would be more 
appropriate to introduce method-categories (as in Smalltalk) in order to 
avoid the mandatory quasi-alphabetical sorting.

(GF sorts them like : bang float grid symbol pointer list, then all other 
names in alphabetical order, then <any> at the very end.)

> for instance, to follow your GFDP model, you'd have one "see also" 
> section that includes [inlet] (which relates to [pd] but not to [table])

The t_class structure of [pd]/[table]/array/abstractions/patches is 
especially hairy. If a single t_class acts like it's many classes at once, 
it may make sense to document it as several classes anyway. However, pd 
will still refer you to a single help file for all those cases (except 
abstractions).

The way a single t_class may act like several, is if it contains 
statements such as

   if (binbuf_getvec(x->te_binbuf)[0]==gensym("thatone")) ...

Then it's looking up which alias has been used for the creation and 
varying the behaviour accordingly. (It could also be using multiple 
creators that store something to remember the same info, or have a single 
creator with multiple names, that stores its t_symbol *s in one way or 
another... I'm talking about all cases of a class acting like it's 
several)

I mean that something can be called a class documentation-wise even though 
it might not be the case implementation-wise. What's important, then, is 
to structure the thought so that people can get the most out of those 
things, and not to document how the code is really written.

But note that if you have a [table whatever] and a [s pd-whatever], you 
can do dynamic-patching instead of the [table], even though the [table] 
won't save the contents. You can try «obj 0 0 inlet» and «obj 0 20 outlet» 
and see that they really add inlets and outlets on a [table] object. Thus, 
in that manner, [inlet] and [outlet] are relevant to [table] objects.

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


More information about the Pd-list mailing list