[PD] libraries in Pd-extended 0.43

[Hans-Christoph Steiner]

On Mon, 2010-12-13 at 20:25 -0800, Jonathan Wilkes wrote:
> 
> --- On Tue, 12/14/10, Mathieu Bouchard <matju at artengine.ca> wrote:
> 
> > From: Mathieu Bouchard <matju at artengine.ca>
> > Subject: Re: [PD] libraries in Pd-extended 0.43
> > To: "Jonathan Wilkes" <jancsika at yahoo.com>
> > Cc: "PD List" <pd-list at iem.at>, "Hans-Christoph Steiner" <hans at 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

> > > 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
> 
> 
>