On Mon, 2010-12-13 at 20:25 -0800, Jonathan Wilkes wrote:
--- 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, 3:04 AM On Mon, 13 Dec 2010, Jonathan Wilkes wrote:
As far as improving documentation, I'd say every
object in Pd-ext should be
documented clearly in a help patch that outlines:
I'd say every class in Pd-ext should be documented clearly in a help patch that outlines:
You're right. I'm an object-o-phile. But do you find "Related Objects" troubling-- should it be "Related Classes"?
Pd doesn't really have classes like OOP (i.e. no inheritance), so I think it can be confusing to use that term. People have been saying objects for a long time with Pd and Max.
.hc
- what the object does
- what the class does
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-- 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]) as well as [tabread] or the "Put" menu array (vice versa). So you can have one help patch for the class that has links to individual objects.
- any related objects (esp. internal objects)
- any related classes (esp. internal classes)
Ok so you do think it should say related classes.
-Jonathan
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC