[PD-dev] $0 in messages, was: multiple $arg-expansion

[IOhannes m zmoelnig]

Hans-Christoph Steiner wrote:
> 
> On Jan 15, 2006, at 4:01 AM, IOhannes m zmoelnig wrote:
> 
> This sounds logical.  I have a question about the selector tho.  So if  
> I send [1 2 3(, would the $0 selector be "list" or would it be "1"?

of course it would be "list", since that'sthe selector of [list 1 2 3(.
[1 2 3( is just a shortcut for [list 1 2 3(

> 
> As for implementing this, we could add $$ as the instance ID, and $0 in  
> messages as the selector.  Then have $0 default to classname in  
> objects, but have a startup flag that reverted $0 to the old behavior  

well this would be simple, though i am not really convinced that it is 
practical - but then, hey, it might really make things better on the 
long run
(an alternative would be to make it a compile.time option ;-))

> for running old patches.  Why we are at it, $# for number of arguments  
> and $@ for all arguments would be nice too.

yes of course, i just forgot to mention that.

>> 2nd thing todo (LATER!) is a mechanism for stacked $args, like ${$1-2}
> 
> 
> Stacked args would complicate things more than its worth.  I think it  
> is getting away from the graphical nature of Pd programming and I can't  
> think of any parallel structure in any language that uses $ variables.   

ähm, bash? like in:
~$ i=3; j=4; echo $[i+2] $[i*$[j+1]]

> Couldn't you just use stacked messages with regular $ args?  That would  
> be much more Pd-ish.

i was thinking of objects where i cannot change the arguments via messages.
[block~] used to be like that (but since 0.39 (or was it 0.38) you can 
now set the blocksiz,... via messages, which makes my argument somewhat 
obsolete; but anyhow...)
writing an abstraction with variable blocksize which is a multiple of 
the variable(!) blocksize of its parent patch would need that.
(while this sounds a bit weird, i am pretty sure i needed to do so 
several times in the past; of course i don't remember the exact context)
btw, there is even an open feature request in the sf-tracker regarding this.

but as i said, it is not very high priority on my todo list


mfg.adsr.
IOhannes