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