--- On Tue, 12/14/10, Mathieu Bouchard <[email protected]> wrote:
> From: Mathieu Bouchard <[email protected]> > Subject: Re: [PD] libraries in Pd-extended 0.43 > To: "Jonathan Wilkes" <[email protected]> > Cc: "PD List" <[email protected]>, "Hans-Christoph Steiner" <[email protected]> > 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"? > > > 1) what the object does > > 1) 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. > > > 5) any related objects (esp. internal objects) > > 5) 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 _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
