[PD] Named arguments for abstractions

Jonathan Wilkes jancsika at yahoo.com
Fri Oct 24 06:47:27 CEST 2014


I think we're talking about the same thing.

In matju's scheme, the abstraction author can make it possible for a user to type something like this:
[myabstraction, something 1 2 3, something_else blah]

After the objects inside myabstraction are instantiated, it would output this from the leftmost inlet inside the abstraction:
something 1 2 3
something_else blah

Then the abstraction author can [route something something_else] in order to use those messages to initialize whatever they want inside the abstraction.  I assume this is what would happen in your scheme after the final [route bang] to the outlet at the end of the patch.

In fact you can do this in Pd Vanilla and obviate the symbol parsing/conversion.  Try this:
[named-arguments foo bar, height 12, cats miaow look ma an arbitrary number of values for this last named "arg"]

Break the list into sequences using [sel,].  It works because Pd's parser converts the comma atoms to symbols consisting of an escaped comma.

And you don't need [initbang] to do any of this.  It's just useful to describe functionality I'm talking about.

-Jonathan



On Friday, October 24, 2014 12:18 AM, Chris McCormick <chris at mccormick.cx> wrote:
 


Hi Jonathan,

I am probably confused, or confusing here, but I was suggesting this as
a mechanism whereby the author of an abstraction could have the
abstraction accept named arguments set by a user of the abstraction.

In that light I am confused by what you've written below, sorry about
that! You seem to be specifying a way for an abstraction to set up
internal defaults, is that right?

I don't have access to "initbang" in the Pd I use yet.

Cheers,

Chris.

On 24/10/14 12:11, Jonathan Wilkes via Pd-list wrote:
> 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 at mccormick.cx> wrote:
> 
> 
> Hi all,
> 
> Here's a design pattern for passing named arguments ("bar=true foo=12")
> into an abstraction.
> 
> Cheers,
> 
> Chris.
> 
> -- 
> http://mccormick.cx/
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> http://lists.puredata.info/listinfo/pd-list
> 
> 
> 
> 
> _______________________________________________
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

> 


-- 
http://mccormick.cx/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20141023/bcfe0f02/attachment.html>


More information about the Pd-list mailing list