[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