[PD] one help patch per class WAS: strange error in console

Hans-Christoph Steiner hans at at.or.at
Wed Jun 16 18:54:41 CEST 2010

On Jun 15, 2010, at 7:15 PM, Martin Peach wrote:

> Hans-Christoph Steiner wrote:
>> On Jun 15, 2010, at 6:58 AM, IOhannes m zmoelnig wrote:
>>> On 2010-06-15 12:48, Matteo Sisti Sette wrote:
>>>>> don't mistake "bad practice IMHO" for "bad practice".
>>>> Of course. But I meant, "do you really think that....?"
>>> me too.
>>> fgmasdr
>>> IOhannes
>> Yes, I really think that its bad practice to have multiple objects  
>> use a single help patch.  We talked about this at length in the  
>> PDDP meetings.  It makes things confusing to newbies and it usually  
>> means the shared help patches don't illustrate the individual  
>> objects well.  The only reason to do it that way is laziness IMHO.
> Well the original post related to [routeOSC] and [unpackOSC] using  
> the same help file. I did that because [unpackOSC] is fairly useless  
> on its own and [routeOSC] won't work without [unpackOSC] ahead of  
> it. Also [slipenc] and [slipdec] are easier to demonstrate using a  
> single help patch. Is having two identical patches with different  
> names somehow better? If I use class_sethelpsymbol the user will get  
> the correct help patch if they right-click 'help'. I suspect most  
> peeps do it that way instead of drilling down into the externals  
> looking for help patches.

This is a good example of what I am talking about.  It would be silly  
to make a help patch for [packOSC] without [unpackOSC], but that  
doesn't mean that they are the same thing.  The [packOSC] help file  
should cover all the possibilities of [packOSC] and use [unpackOSC]  
and whatever else to illustrate them.  Adding all the possibilities of  
[unpackOSC] to the [packOSC] unnecessarily complicates the [packOSC]  
help patch.  Therefore there should also be an [unpackOSC] help patch.



All information should be free.  - the hacker ethic

More information about the Pd-list mailing list