[PD-dev] [ pure-data-Patches-1543850 ] $@ and $# expansion (argc, argv)

[Hans-Christoph Steiner]

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.

.hc


------------------------------------------------------------------------

If you are not part of the solution, you are part of the problem.