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