[PD] dealing with arguments and inlets

[Hans-Christoph Steiner]

On Feb 4, 2006, at 3:58 PM, Mathieu Bouchard wrote:

> On Sat, 4 Feb 2006, Hans-Christoph Steiner wrote:
>
>> I think we can keep both [any_argument] and [list_argument] so that  
>> you can
>> choose the behavior.  Also its very easily and logically  
>> straightforward to do
>> this if you want:
>>
>> [any_argument]
>> |
>> [route float]
>>             [symbol]
>>
>> And this will work even with very old versions of Pd and would be  
>> compatible
>> with [list_argument].
>
> This wouldn't work with pointers. This also wouldn't work if Pd's set  
> of
> basic atomtypes (float symbol pointer) gets extended to more types in  
> the
> future.
>
>> In my opinion, new is not always better.  The double [route] thing  
>> works
>> fine, and it is a clearly established method.  [list] is still quite
>> new, so for things like [*_arguments], I think its wise to stick to
>> tried-and-true methods whenever possible.
>
> tried-and-true is ok if the new [list] thingy doesn't fill a gap in Pd.
> But it does fill a big gap, such that anything designed for >=0.39  
> which
> avoids using [list] is just being retro. It's not like [list] is some  
> kind
> of luxury, isn't it?

Ok, I'm convinced on that point, [list_argument] should use list.  I  
support backwards compatibility only if it doesn't affect forward  
compatibility.  My concern is that since [list] is new an untested, and  
something of a hack (i.e. alist_class) that is might have to change  
behavior at some point in the future.  It doesn't feel stable to me  
yet.

But I still think that [any_argument] that outputs a non-symbol is  
useful too.  How about this:  [list_argument] becomes [any_argument],  
since its symbol output matches [symbol_argument], then the non-list  
[any_argument] is [route_argument] or something like that.

.hc

________________________________________________________________________ 
____

                     There is no way to peace, peace is the way.
						        				-A.J. Muste