[PD-dev] Message dispatching system

Jonathan Wilkes jancsika at yahoo.com
Sun Jun 16 21:28:26 CEST 2013





________________________________
 >From: Miller Puckette <msp at ucsd.edu>
>To: Jonathan Wilkes <jancsika at yahoo.com> 
>Cc: pd-dev at iem.at 
>Sent: Sunday, June 16, 2013 12:53 PM
>Subject: Re: [PD-dev] Message dispatching system
 

>It's a general rule - it was the easiest way to code it portably.  If you
wanted to truly intersperse floats and integer/pointers you'd have something
like a 32-case switch statement to generate the function calls.

I understand that part of the design.  But the other general rule is that
the order of args one specifies in the class_addmethod definition fits the
order of args as they appear in the c function definition.  That's why I asked
specifically about graph_array and why it does not follow this general rule.

Both general rules are sensible IMO.

-Jonathan

cheers
Miller

On Mon, May 20, 2013 at 01:41:06PM -0400, Jonathan Wilkes wrote:
> Hi list,
>      I learned some more about Pd's message dispatching system while
> adding jump-on-click mouse clicks and bar graphs to "Put" menu
> arrays:
> 
> 1) For type-checked args in class_addmethod, you can specify them in
> any order.
> 2) Pd re-arranges them, putting the symbol/pointer args first and
> the float args last.
> 3) In the function for the method you have to specify the args in
> the order from #2.
> 
> I see graph_array makes use of these in g_graph.c: the args are
> symbol float symbol float float, but the function receives the
> symbols as the first two args.
> 
> Was this done to fix a bug or keep something backwards compatible?
> Are there other methods done this way?  In general I think it's much
> better to specify type-checked args in the same order they'll be
> received by the function, meaning symbols/pointers then floats.
> Otherwise it makes it more difficult to track down errors.
> 
> -Jonathan
> 
> _______________________________________________
> Pd-dev mailing list
> Pd-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20130616/6e8d62d9/attachment.htm>


More information about the Pd-dev mailing list