--- On Tue, 12/14/10, Mathieu Bouchard <ma...@artengine.ca> wrote:
> From: Mathieu Bouchard <ma...@artengine.ca>
> Subject: Re: [PD] libraries in Pd-extended 0.43
> To: "Jonathan Wilkes" <jancs...@yahoo.com>
> Cc: "PD List" <pd-list@iem.at>, "Hans-Christoph Steiner" <h...@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
_______________________________________________
Pd-list@iem.at mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
