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

[Hans-Christoph Steiner]

On Jan 15, 2006, at 12:38 PM, IOhannes m zmoelnig wrote:

> 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]]

Ah, I guess I am stuck on good ol' bourne shell ;).  But isn't that  
bash stuff just a hack to get math into bourne shell syntax?  I don't  
think its the kind of thing we want to emulate.

>
>> 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

I think that its much cleaner to make the objects receive messages on  
inlets than get into the whacky bash syntax.

.hc

________________________________________________________________________ 
____

"Information wants to be free."
                                      -Stewart Brand