Finally, we agree. I also think, that using $ twice is confusing, when the uses are so different.
Personally, i wouldn't mind, if Pd would be changed instantaneously while breaking backwards compatibility. But i don't think, that it is realistic.
roman
On Fri, 2009-11-13 at 13:16 -0800, Phil Stone wrote:
Matt Barber wrote:
I am saying two things:
- Without $0 or something similar, the only way to guarantee similar
locality would be through use of $1 or $n -- you would have to manually give each instance an instance number. Sometimes you even want to be able to group instances in the way you suggested. I'm not sure of the history of Pd, but if $0 was implemented after abstractions with arguments, then manually assigning locality was probably necessary.
- Sometimes $0 NEEDS to be inherited (probably as $1 or some such) by
various helper abstractions within a larger, higher-functioning abstraction. This is especially the case with dynamic patching -- imagine, say, a "bell synthesis" patch using a dynamically created bank of enveloped oscillator abstractions. In that case, you'd want each oscillator abstraction to [throw~] to the same [catch~] within the parent "instrument" abstraction. To do this, you could have [catch~ $0-out] within the parent, and [throw $1-out] within each child, while passing the parent's $0 to the children.
So all I'm saying is that $1-$n often plays a really important role in locality, in addition to a number of other things, and to me it seems almost natural to use $0 as an analogy for this role.
Good points, all.
I personally love the idea of using $0 as the selector of the abstraction -- its name or filename, and $$ as its ID, but too late for that now.
I can't disagree with this, either. Though, in the spirit of wishful thinking, I'll go it one further: abstraction arguments would ideally have a different form than message arguments. E.g. #0...#n for message args., and $0...$n for abstraction args. (or, the other way around, whatever)... Then (and only then, I think) would this discussion not be