passing parameters in a send call.

[Dar Scott]

On May 22, 2006, at 9:00 AM, Graham Samuel wrote:

> Isn't it true that
>
>    send "myCmd x,y" to...
>
>  just sends that exact string (minus the quotes)  to the target: if  
> so, the target environment can only resolve x and y if it's in the  
> same name space as the script that did the sending (I mean if it is  
> able to evaluate x and y), which is in general not true (after all,  
> the point of handler parameters is to pass information from one  
> context to another). So if I'm right
>
>    send "myCmd"& x &","& y to...
>
> first evaluates x and y in the context of the sender (which is what  
> Sarah said) and therefore achieves the expected result, whereas the  
> other method doesn't. Arrays being a special case may not work  
> anyway, but I'm trying to make a more general point.
>
> I hope what I've just written makes sense.

This makes sense.

Jim created a counter example that shows this is not true for custom  
commands.

(I don't remember all the details, but I think that that is not the  
case for built-in commands or for parameter expressions that refer to  
objects, so let's ignore those for now.  Some of that is covered  
briefly in my "Message Mechanics" stack.)

So the difference between 'do' and 'send' is small.  Both compile and  
then execute the first step of evaluating parameters and bundling  
them up with the command name.  Then that gets dropped down the  
message path.  For 'do', it is the path starting at 'me', but for  
'send' the path starts at the specified target (and at the clock time  
implied by the time delta) with a current stack switch.

You can even include a comment in a 'send', but I don't know of any  
benefit.

The method of building a 'send' message with literal parameters has  
problems with parameters contain quote marks or commas.

Long ago I tried to come up with fancy ways to create the right  
literals until I discovered I could use variables in the command  
string.  I now encourage that.

Dar