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
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.
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:
- 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@iem.at http://lists.puredata.info/listinfo/pd-dev
________________________________
From: Miller Puckette msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: pd-dev@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:
- 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@iem.at http://lists.puredata.info/listinfo/pd-dev
There's no rule governing the order of floats vs. symbols in a message's argument list - although typicaly when designing messages I put the floating point numbers last since most messages have some structure like (functions, flags and filenames) (numerical parameter or two). But that's just a tendency, which gets broken now and then in my code and probably also in other peoples' - I think it can be regarded as programming style.
cheers Miller
On Sun, Jun 16, 2013 at 12:28:26PM -0700, Jonathan Wilkes wrote:
From: Miller Puckette msp@ucsd.edu To: Jonathan Wilkes jancsika@yahoo.com Cc: pd-dev@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:
- 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@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Jonathan Wilkes -
Miller Puckette