--- On Tue, 12/14/10, Mathieu Bouchard matju@artengine.ca wrote:
From: Mathieu Bouchard matju@artengine.ca Subject: Re: [PD] libraries in Pd-extended 0.43 To: "Jonathan Wilkes" jancsika@yahoo.com Cc: "PD List" pd-list@iem.at, "Hans-Christoph Steiner" hans@at.or.at Date: Tuesday, December 14, 2010, 4:36 PM 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).
Yeah, so currently I have links inside canvas-help.pd to
table-help.pd, pd-help.pd, graph-help.pd, and a special note
about "Put" menu arrays with a link to array-help.pd.
array-help.pd is necessary to have there because triggering the
help patch for the "Put" menu array is so obscure (I wonder if
anyone here even knows what to click to get it.)
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.
That's true, but just because it's possible to do that doesn't mean that [inlet] and [outlet] are relevant enough to show in the help patch for [table], any more than showing [list] in the help patch for [metro].
Also, it doesn't work the other way around-- [tabread], [tabwrite], etc. are not relevant to [pd].
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC