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