Should "dispatch" be extended for timers?

[Devin Asay]

On Aug 29, 2014, at 6:58 AM, Trevor DeVore <lists at mangomultimedia.com>
 wrote:

> On Tue, Aug 26, 2014 at 10:09 PM, Richard Gaskin <ambassador at fourthworld.com
>> wrote:
> 
>> 
>> Is there some reason I've overlooked as to why "send" allows timers but
>> "dispatch" doesn't?
> 
> 
> I don't know if there is a reason dispatch doesn't have timers, but what if
> "send" was just updated to support "with"? If "with" was present then we
> could do this:
> 
> send "someCommand" to someObject with param1, param2 in 10 milliseconds
> 
> The thing is, dispatch is useful if A) you want to know if the command was
> handled, B) you want to send a message and you don't care if it is handled
> (the engine doesn't report an error if "someCommand" isn't defined
> anywhere), or C) you want to call a command/function outside of the message
> path. I see this as a much improved version of the 'send "someCommand"'
> form of 'send'.
> 
> Given how dispatch works, I see 'send is' as being what you use if you want
> to execute some code after the current event loop has finished executing.
> The downside is that the syntax stinks. But if the syntax were updated so
> that it supported the same form as dispatch then I think it would be great.
> I imagine the engine could also improve the speed to be on par with
> dispatch as the engine would know that "someCommand" wouldn't contain any
> variables that had to be processed (e.g. "someCommand param1, param2").

+1

I've often thought 'send [command] with [params]' would be a great enhancement. There's always a little apprehension and confusion over whether the variable names in quotes in 'send [command param,param]' will be parsed properly.

Devin


Devin Asay
Office of Digital Humanities
Brigham Young University