Scripts that are already running

[Phil Davis]

  Richard's approach would be my approach also. It's usually easier to make the 
solution overly complex, than to make it this simple.

Phil Davis


On 9/24/10 11:12 AM, Richard Gaskin wrote:
> DunbarX wrote:
>
>> This all came about because someone wanted a single universal watchdog on
>> his stack. He had several handlers in several places, all of which could
>> create a condition he wanted to act upon. So the "send in time" handler fit that
>> bill. If he created yet another such handler somewhere, it would be
>> covered. But it occurred to be that if the condition was met and the handler 
>> still
>> had much to do and might take a long time to do it, then the condition could
>> not be dealt with until that handler ends. It seemed intriguing to think
>> that something could monitor, say, the state of variables, from outside the
>> handler while it was running.
>>
>> Anyone think this is a useful, perhaps monumental, feature?
>
> Indeed it would:
>
> Add Threaded messaging and or execution in Transcript
> <http://quality.runrev.com/qacenter/show_bug.cgi?id=2832>
>
> But threading comes with an additional level of responsibility.  Right now we 
> almost never have to worry about race conditions, an area where a lot of 
> programmers using threaded languages spend thousands of hours each year 
> debugging hard-to-track-down issues.
>
> Once you introduce threading into the language it's like handing someone a 
> loaded gun with a map to their foot.  Still very useful, and well worth 
> implementing, but it would so fundamentally change the messaging system that 
> it would raise the learning curve and open up many new ways to make mistakes. :)
>
> For those who need it threading would be a godsend, and RunRev couldn't add 
> this fast enough for me.  Many server processes could be much more optimized 
> with a threaded implementation.
>
> In the meantime, for single-user apps working within a non-threading system 
> isn't usually so bad.  As we've seen in this example, it usually requires no 
> more than a single line of code to have any additional checking happening 
> inside of any handler you like, and with that requirement it leaves the 
> scripter explicitly in control of the interactions between things.
>
> For property settings this might even be reduced to zero additional lines of 
> code in the repeat loop if you include a setProp handler that will respond to 
> the change:
>
> -- Main handler:
>
> on mouseUp
>   repeat with i = 1 to 100
>      set the uMyProp of this stack to i
>   end repeat
> end mouseUp
>
>
> -- In stack script, library, or any other place in the
> -- message path:
>
> setProp uMyProp pValue
>   if pValue = 50 then
>     DoSomethingCool
>   end if
> end uMyProp
>
>
> It can be tempting to use getProp and setProp in places where more 
> controllable and concise function and command calls can work well as 
> accessors, but when you need 'em they're handy to have available.
>
> -- 
>  Richard Gaskin
>  Fourth World
>  LiveCode training and consulting: http://www.fourthworld.com
>  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
>  LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

-- 
Phil Davis

PDS Labs
Professional Software Development
http://pdslabs.net