[PD] abstraction setting its own arguments

[Mathieu Bouchard]

On Sat, 31 Jul 2010, Jonathan Wilkes wrote:

> * the magical [inlet] message on loadbang is weird and will cause a
> crash in winxp if you happen to remove the abstraction's inlet.

You mean you don't get the following error message ?

« error: [args hello (world a 42) *] inlet 0 method loadbang:
   can't send init-messages, because object has no [inlet] »

> * sending output from [args] on loadbang is redundant when
> [loadbang]-[args] is so trivial.

lots of shortcuts are trivial individually, then pile up to make a 
difference.

The problem with auto-[loadbang] in args is that [loadbang] order is a 
dangerous thing (which I forgot to think about when designing that part of 
[args]... not sure what to do with it now... a bit hard to undo).

> Is there anything [args] can currently do that wouldn't be possible by 
> taking an "anything" at its inlet?

What would be the meaning of that "anything" ?

you mean plugging [loadbang]-[list append $@] into it ?... maybe it would 
work, but it would be two more objects per abstraction, too. (and it 
wouldn't be a "anything". why "anything" ?)

> Additionally, your method of using commas to separate named init values 
> assumes that the pd programmer doesn't want to send commas as arguments 
> (which I did want to do in my [expr] example).

I expect to add this feature whenever someone needs it :

   [args *, nocommas]

would consider commas as non-special. Also :

   [args *, nocommas, noparens]

would completely disable special parsing. But it's also possible that the 
syntax would be :

   [args *, commas 0, parens 0]

a 0/1 attribute specified without a value defaults to 1. I haven't really 
thought about a rule for what is better, negative bools (names with "no" 
in them) when they sound good (mainly for exceptional cases), or positive 
bools all over.

> So what I'm saying is that your [args] doesn't fit my needs, and $@ 
> wouldn't fit everyone's needs, but $@ + [args] + 
> [other_parsers_as_needed] would fit the maximum number of needs

You know, passing [loadbang]-[list append $@]-[args] isn't making [args]'s 
code any shorter than with an autonomous [args] as it is now.

And then, for the handling of abstractions' properties dialogues, I'm 
going to do something rather close to a list-method for [args], without 
doing it : I'm going to use [setargs] just before re-banging the [args]. 
It's the only way I can think of using [args] with an input that is not 
just the original arguments of the abstraction-instance...

> without burdening the users with learning a completely different way of 
> getting args every time they want to do something different with them.

I'm all for adding $@ to pd-extended, but by itself, its inclusion in 
pd-extended doesn't seem like a reason to change anything in [args] at 
all. In any case, if you feel like $@ has to be included in pd-extended, 
that's something you have to talk to Hans about.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard, Montréal, Québec. téléphone: +1.514.383.3801