Re: [PD] Named arguments for abstractions

Hi Chris, I prefer the idea of using the comma atom to send messages to an object/abstraction at init time.

Example: [bar 15 25( | [foo]

would be equivalent to

[initbang] | [foo, bar 15 25] Benefits:

• messages can be type-checked or arbitrary length, just like any pd message
• eases development of externals. For instance, sigmund~ would have had 96 fewer lines of code because this syntax would have done away with the need for flags
• it looks like message-box syntax and behaves nearly the same
• once implemented, it would automatically apply (consistently) to every internal/external object
• matju already implemented it in Gridflow

Drawbacks:

• [expr], [list], [select], [route], and a few others would need to be treated specially to retain their current behavior regarding commas
• abstractions require some mechanism to retrieve those init-time messages. I believe matju had them shoot out the leftmost inlet of the abstraction, with the assumption that the user would have a [route] sitting there to parse them. Another idea would be to retrieve them from an introspection object like [canvasinfo] (and maybe have another object which splits that into a sequence of messages).

-Jonathan

On Thursday, October 23, 2014 11:28 PM, Chris McCormick chris@mccormick.cx wrote:

Hi all,

Here's a design pattern for passing named arguments ("bar=true foo=12") into an abstraction.

Cheers,

Chris.