[PD-dev] [ pure-data-Patches-1543850 ] $@ and $# expansion (argc, argv)
hans at eds.org
Wed Aug 23 17:53:09 CEST 2006
On Aug 23, 2006, at 3:46 AM, IOhannes m zmoelnig wrote:
>>> Comment By: Hans-Christoph Steiner (eighthave)
>> Date: 2006-08-22 18:21
>> Yes! This is great!
>> As for the selector, $0 is not taken in message space, so I
>> think it makes sense there. Since message expansion
>> variables are already different than object arguments, I
>> think that won't be too confusing. Plus the $ variable
>> syntax comes from shell scripting, where $0 is basically the
>> selector of the message that is the command line arguments.
> i don't agree.
> if pd was bash, $0 would be the selector (or object name); $1,...
> would be the numbered arguments (as they already are); in bash, $$
> is the "process id", which could roughly map to the canvas id in
> objects (what is currently $0)
> however, pd is not bash.
> $1 in object boxes and messages boxes has the same meaning in a
> different context. (i know this is kind of a weak argument since it
> derives the idea from the implementation, but: on the C-level of
> pd, the entire expansion thing is handled by one function; there is
> no separation between objects & messages)
> $0 has a meaning in objects (which is unfortunately not consistent
> with $1), but no meaning in messages.
> this does not mean, that we are free to use it for whatever we want.
> for me the selector of a message is structurally the same as the
> object name (the "selector" of the object), therefore they should
> have the same expansion-symbol.
> since $0 is taken (for good or bad), we have to find an
> alternative, (if we really think we need a selector-expansion).
> a meaning for $0 in messages could be a "timestamp". ("objects" are
> "images", spatial entities; contrary, the basic property of
> "messages" is there position in time; so arbitrary messages could
> be grouped together bythis property: messages at the same moment
> have the same $0)
I think we agree with the overall logic, just not the solution. I
think in general, we spend way too much effort remaining backwards
compatible and it cripples the development of Pd. All of the old
versions are freely available, if you need to run an old patch, you
can easily use an old version of Pd.
The whole $ argument scheme has been laid out and clearly defined for
a very long time. I think its a bad idea to use the $ argument
scheme, then invert the meaning of a couple of parts. That will
inevitably lead to people wasting many hours debugging things because
they expected a normal $ argument scheme. This kind of kludgey,
patch-fix progress has led to things like the symbol atom/symbol
message madness, and the convoluted logic of Max's/Pd's list/set
handling, or that $0 was used as process ID. We need less of these
headaches, not more.
Instead, we need to start to take a step back and look at the bigger
picture, and think about how it should have been done had there been
no backwards compatibility issues.
I think we should implement the whole $ argument scheme the right
way, like in bash, perl, tcsh, etc. etc. Or use a different scheme.
For a transition, it would be possible to have a flag that switched
$0 to the old behavior. Or many other possible solutions. We could
have API version declarations, so that a patch can declare which
version of the API it needs, then Pd would adjust accordingly. This
could also be done with a startup flag.
If you are not part of the solution, you are part of the problem.
More information about the Pd-dev