[PD] libraries in Pd-extended 0.43

[Mathieu Bouchard]

On Tue, 14 Dec 2010, Jonathan Wilkes wrote:

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

I don't know how you can possibly not get it. Do you expect that you can 
get it by right-clicking the array's label ? Because, it doesn't work for 
any other label (IEMGUI...), so, why would it work for Array's label ?

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

Actually, when you have a [table], you don't have one object, you have two 
of them. When you have [table foo], receive-symbol "pd-foo" sends to a 
canvas, whereas receive-symbol "foo" sends to the internal t_array object, 
which has all of the array-specific methods. This has to be made clear, 
because it's not like an inheritance-like pattern.

An inheritance-like pattern (or interface pattern) would be, for example, 
to have one single help-patch for most of the common methods in iemguis, 
those that have exactly the same behaviour, to emphasise that they are one 
single family (even though inheritance in pd is mostly in our 
imagination). It's a matter of documenting things in a non-repetitive, 
synthetic manner, and with a mindset that encourages consistency.

When you have one class that seemingly would include one complete other 
helpfile's content but not the other way around, that would usually be an 
inheritance pattern, but it's not here, because instead, it's mostly that 
a canvas has a t_array tacked onto it, vs not.

It can't be called delegation pattern either, because in a delegation 
pattern, you have two objects, of which you only send to one, which will 
forward the message to the other one whenever appropriate. This is not the 
case here, because you can send to two different receive-symbols, and you 
have to send to the correct one.

I could have said a lot less, but I just thought I'd give you some more 
doc ideas.

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC