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
_______________________________________________
use-revolution mailing list
use-revolution@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution